Part V Transitioning Between Naming Services

This section describes how to transition from NIS to and NIS+ as well as from NIS+ to LDAP.

Chapter 26 Transitioning from NIS to NIS+

This chapter introduces the issues involved in converting from the NIS naming service to the NIS+ naming service. It describes the differences between the two name services and outlines a suggested transition process.

NIS+ might not be supported in a future release. Tools to aid the migration from NIS+ to LDAP are available in the Solaris 9 operating environment (see Part V). For more information, visit http://www.sun.com/directory/nisplus/transition.html.

Differences Between NIS and NIS+

NIS and NIS+ have several differences with an impact on a transition. For example, NIS uses a flat, non-hierarchical namespace with only one domain (or several disconnected domains), while NIS+ provides a domain hierarchy similar to that of DNS. This means that before you can convert to NIS+, you must design the NIS+ namespace. NIS+ also provides security, which limits access not only to the information in the namespace but also to the structural components of the namespace.

These and other differences demonstrate that NIS+ is not only an upgrade to NIS but is an entirely new product. Therefore, the transition from NIS to NIS+ is largely directed by the differences between the products.

These differences are described in broad terms in the remainder of this chapter. Understanding them is critical to a successful transition to NIS+. They are the following.

• Domain structure.

• Interoperability.

• Server configuration.

• Information management.

• Security.

Domain Structure

NIS+ is not only an upgrade to NIS; it is designed to replace NIS. This becomes evident when you examine its domain structure. NIS domains are flat and lack the ability to have a hierarchy. NIS+ domains may be flat, but you can also construct hierarchical NIS+ domains. Such hierarchies consist of a root domain with an infinite number of subdomains under them.

The NIS domain structure addressed the administration requirements of client-server computing networks prevalent in the 1980s, in other words, client-server networks with a few hundred clients and a few multipurpose servers.

NIS+ is designed to support networks with 100 to 10,000 clients supported by 10 to 100 specialized servers located in sites throughout the world, connected to several “untrusted” public networks. The size and complexity of these networks requires new, autonomous administration practices. The NIS+ domain structure was designed to address these requirements. It consists of hierarchical domains similar to those of DNS, as shown in the following diagram:

Figure 26–1 NIS+ Domains

Hierarchical domains allow NIS+ to be used in a range of networks, from small to very large. They also allow the NIS+ service to adapt to the growth of an organization. The NIS+ domain structure is thoroughly described in Domains.

DNS, NIS, and NIS+ Interoperability

NIS+ provides Interoperability features designed for upgrading from NIS and for continuing the interaction with DNS originally provided by the NIS service. To help convert from NIS, NIS+ provides an NIS-compatibility mode and an information-transfer utility. The NIS-compatibility mode enables an NIS+ server running in the Solaris operating environment to answer requests from NIS clients while continuing to answer requests from NIS+ clients. The information-transfer utility helps administrators keep NIS maps and NIS+ tables synchronized.

NIS-compatibility mode requires slightly different setup procedures than those used for a standard NIS+ server. Also, NIS-compatibility mode has security implications for tables in the NIS+ namespace.

NIS client machines interact with the NIS+ namespace differently from NIS+ client machines when NIS+ servers are running in NIS-compatibility mode. The differences are:

• NIS client machines cannot follow NIS+ table paths or links, or do read operations in other domains.

• NIS client machines can have their unsatisfied host requests forwarded to DNS if you run rpc.nisd with the -Y -B options, but the NIS+ server will not forward these requests for an NIS+ client. DNS request forwarding for NIS+ client machines is controlled by the /etc/resolv.conf and /etc/nsswitch.conf files' configurations. See Chapter 1, The Name Service Switch for more information.

• Authorized NIS+ administrators can use the passwd command to perform the full range of password-related administrative tasks, including password aging and locking. NIS+ client users can use the passwd command to change their own passwords.

• Even if all the servers on a local subnet no longer respond, the NIS+ client machines can still have their name service calls answered if they can contact any of the replicas of that domain. NIS client machines do not have access to information on the network outside their subnet unless the server names have been set with ypset or, for Solaris NIS clients only, with ypinit.

• NIS client machines cannot be sure that the data they are receiving comes from an authorized NIS server, while authorized NIS+ clients are certain that the data is coming from an authorized NIS+ server.

• Under NIS, if the server is no longer responding, the NIS yp_match() call continues to retry this call until the server responds and answers the request. The NIS+ API (Application Programming Interface) returns an error message to the application when this situation occurs.

In the Solaris 2.3 release, the NIS-compatibility mode supports DNS forwarding. In the Solaris 2.2 release, support for DNS forwarding is available as a patch (patch #101022-06). The DNS forwarding patch is not available in the Solaris 2.0 and 2.1 releases.

Although an NIS+ domain cannot be connected to the Internet directly, the NIS+ client machines can be connected to the Internet with the name service switch. The client can set up its switch-configuration file (/etc/nsswitch.conf) to search for information in either DNS zone files or NIS maps—in addition to NIS+ tables.

Server Configuration

The NIS+ client-server arrangement is similar to those of NIS and DNS in that each domain is supported by a set of servers. The main server is called the master server, and the backup servers are called replicas. Both master and replica servers run NIS+ server software and both maintain copies of NIS+ tables.

However, NIS+ uses an update model that is completely different from the one used by NIS. At the time NIS was developed, it was assumed that most of the information NIS would store would be static. NIS updates are handled manually, and its maps have to be remade and fully propagated every time any information in the map changes.

NIS+, however, accepts incremental updates to the replicas. Changes must still be made to the master database on the master server, but once made, they are automatically propagated to the replica servers. You do not have to “make” any maps or wait hours for propagation. Propagation now takes a matter of minutes.

Information Management

NIS+ stores information in tables instead of maps or zone files. NIS+ provides 17 types of predefined or system tables, as shown in Figure 26–2.

Figure 26–2 NIS+ Standard Tables

NIS+ tables are not ASCII files, but are tables in the NIS+ relational database. You can view and edit their contents only by using the NIS+ commands.

NIS+ tables provide two major improvements over the maps used by NIS. First, an NIS+ table can be searched by any searchable column, not just the first column (sometimes referred to as the “key”). To know whether a particular column is searchable, run the niscat -o command on a table. The command returns a list of the table's columns and their attributes, one of which is whether a column is searchable. This search ability eliminates the need for duplicate maps, such as the hosts.byname and hosts.byaddr maps used by NIS. Second, the information in NIS+ tables has access controls at three levels: the table level, the entry (row) level, and the column level.

NIS maps are located on the server in /var/yp/domainname, whereas NIS+ directories are located in /var/nis/data. The NIS+ tables are contained in the database. The tables' information is loaded into memory as requests are made to the database. Keeping data in memory in the order requested minimizes calls to the disk, thereby improving request response time.

Security

The security features of NIS+ protect the information in the namespace and the structure of the namespace itself from unauthorized access. NIS+ security is provided by two means: authentication and authorization. Authentication is the process by which an NIS+ server identifies the NIS+ principal (a client user or client machine) that sent a particular request. Authorization is the process by which a server identifies the access rights granted to that principal, whether a client machine or client user.

In other words, before users can access anything in the namespace, they must be authenticated NIS+ clients and they must have the proper permission to access that information. Furthermore, requests for access to the namespace are only honored if they are made either through NIS+ client library routines or NIS+ administration commands. The NIS+ tables and structures cannot be edited directly.

Suggested Transition Phases

The following outline is a suggested NIS-to-NIS+ transition:

1. Review basic transition principles.

2. Become familiar with NIS+.

3. Design your final NIS+ namespace.

4. Select security measures.

5. Decide how to use NIS-compatibility mode.

6. Complete prerequisites to transition.

7. Implement the transition.

The remainder of this chapter is a detailed discussion of these transition phases.

Transition Principles

Before you begin the transition, you should review the following basic principles:

Consider the Alternatives to Making the Transition Immediately

You can defer the upgrade to NIS+ until after your site has completed its transition to the Solaris operating environment. This allows you to focus your resources on one transition effort at a time. You can continue to run NIS under the Solaris operating environment until you are ready to make the transition to NIS+.

Keep Things Simple

You can take several steps to simplify the transition. While these steps will diminish the effectiveness of NIS+, they will consume fewer servers and less administrative time. After the transition is complete, you can change the NIS+ setup to better suit your needs. Here are some suggestions:

• Do not change domain names.

• Do not use any hierarchies; keep a flat NIS+ namespace.

• Use the NIS-compatibility features.

• Use default tables and directory structures.

• Do not establish credentials for clients, if you are running the Solaris 2.5 Release or later.

Use a Single Release of Software

Decide which version of the Solaris operating environmenta and NIS+ you will use for the transition. Because there are slight differences between versions, using multiple versions could needlessly complicate the transition process. Choose one version of the Solaris product and use its corresponding version of NIS+.

The current release has the most features (such as setup scripts). Make sure you compile a list of the Solaris operating environment patches that are required for normal operation, and make sure that all servers and clients have the same patches loaded.

Minimize Impact on Client Users

Consider the two major user-related factors: First, users should not notice any change in service. Second, the transition phase itself should cause minimal disruption to client users. To ensure the second consideration, be sure the administrators responsible for each domain migrate their client machines to NIS+, rather than ask the users to implement the migration. This ensures that proper procedures are implemented, that procedures are consistent across client machines, and that irregularities can be dealt with immediately by the administrator.

Things You Should Not Do

• Do not change the name services currently provided by NIS or change the way NIS functions.

• Do not change the structure of DNS.

• Do not change the IP network topology.

• Do not upgrade applications that use NIS to NIS+; leave the migration to NIS+ APIs for the future.

• Do not consider additional uses for NIS+ during the implementation phase; add them later.

Become Familiar With NIS+

Familiarize yourself with NIS+, particularly with the concepts summarized earlier in this chapter and discussed in the remainder of this book.

One of the best ways to become familiar with NIS+ is to build a prototype namespace. There is no substitute for hands-on experience with the product; administrators need the opportunity to practice in a forgiving test environment.

Do not use your prototype domain as the basis for your actual running NIS+ namespace. Deleting your prototype after you have learned all you can from it will avoid namespace configuration problems. Start anew to create the real namespace after following all the planning steps.

When you create the test domains, make small, manageable domains. See Creating a Sample NIS+ Namespace, which describes how to plan and create a simple test domain and subdomain (with or without NIS-compatibility mode), using the NIS+ setup scripts.

The NIS+ scripts described in are the recommended method for setting up an NIS+ namespace. The recommended procedure is to first set up your basic NIS+ namespace using the scripts, then customize that namespace for your particular needs, using the NIS+ command set.

Design Your Final NIS+ Namespace

Design the final NIS+ namespace, following the guidelines inPlanning the NIS+ Namespace: Identifying the Goals of Your Administrative Model . While designing the namespace, do not worry about limitations imposed by the transition from NIS. You can add those later, after you know what your final NIS+ goal is.

Plan Security Measures

NIS+ security measures provide a great benefit to users and administrators, but they require additional knowledge and setup steps on the part of both users and administrators. They also require several planning decisions. Understanding the Impact of NIS+ Security describes the implications of NIS+ security and the decisions you need to make for using it in your NIS+ namespace.

Decide How to Use NIS-Compatibility Mode

The use of parallel NIS and NIS+ namespaces is virtually unavoidable during a transition. Because of the additional resources required for parallel namespaces, try to develop a transition sequence that reduces the amount of time your site uses dual services or the extent of dual services within the namespace (for example, convert as many domains as possible to NIS+ only).

Before You Transition to NIS+: Gauge the Impact of NIS+ on Other Systems explains the transition issues associated with the NIS-compatibility mode and suggests a way to make the transition from NIS, through NIS compatibility, to NIS+ alone.

Implement the Transition

Implementing NIS+: An Introduction provides suggested steps to implement the transition you have planned in the previous steps.

Planning the NIS+ Namespace: Identifying the Goals of Your Administrative Model

When designing the namespace, do not worry about limitations imposed by the transition from NIS. You can modify your NIS+ domain later, after you know how your final NIS+ configuration will look.

Select the model of information administration, such as the domain structure, that your site will use. Without a clear idea of how information at your site will be created, stored, used, and administered, it is difficult to make the design decisions suggested in this section. You could end up with a design that is more expensive to operate than necessary. You also run the risk of designing a namespace that does not suit your needs. Changing the namespace design after it has been set up is costly.

Designing the Namespace Structure

Designing the NIS+ namespace is one of the most important tasks you can perform, since changing the domain structure after NIS+ has been set up is a time-consuming, complex job. It is complex because information, security, and administration policies are woven into the domain structure of the namespace. Rearranging domains requires rearranging information, reestablishing security, and recreating administration policies.

When designing the structure of an NIS+ namespace, consider the factors which are discussed in the following sections of this chapter:

Domain Hierarchy

The main benefit of an NIS+ domain hierarchy is that it allows the namespace to be divided into more easily managed components. Each component can have its own security, information management, and administration policies. It is advisable to have a hierarchy when the number of clients you have exceeds 500, if you want to set up different security policies for a set of users, or if you have geographically distributed sites.

Unless there is a need for a domain hierarchy, not having a hierarchy can simplify your transition to NIS+. When all users were in the same NIS domain, they were directly visible to each other without using fully qualified names. Creating an NIS+ hierarchy, however, puts users in separate domains, which means that the users in one domain are not directly visible to users in another domain, unless you use fully qualified names or paths.

For example, if there are two subdomains, sales.com. and factory.com., created out of the earlier .com. domain, then for user juan in the sales.com. domain to be able to send mail to user myoko in factory.com., he would have to specify her name as myoko@hostname.factory.com. (or myoko@hostname.factory) instead of just myoko, as was sufficient when they were in the same domain. Remote logins also require fully qualified names between domains.

You could use the table path to set up connections between tables in one domain and another domain, but to do so would negate the advantages of having a domain hierarchy. You would also be reducing the reliability of the NIS+ service because now clients would have to depend upon the availability of not only their own home domains, but also of other domains to which their tables are pathed. Using table paths may also slow request response time.

Domain Hierarchy – Solaris 2.6 and Earlier

In Solaris 2.6 and earlier, the NIS+ servers for each subdomain are not part of the subdomain that they serve, with the exception of the root domain. The NIS+ servers are in the parent domain of the subdomain they serve. This relationship of server to subdomain creates problems for applications that expect the servers to be able to get their name-service data from the subdomain. For example, if a subdomain NIS+ server is also an NFS server, then the server does not get its netgroups information from the subdomain; instead, it retrieves the information from its domain, which is the domain above the subdomain; this can be confusing. Another example of when a hierarchy can cause problems is where the NIS+ server is also used by users to log in remotely and to execute certain commands that they cannot execute from their own machines. If you have only a single root domain, you do not have these problems because NIS+ root servers live in the domain that they serve.

Domain Hierarchy – Solaris 9

In the Solaris operating environment, the NIS+ server for a domain can be in the same domain it serves. This allows a server to set its domain name to the same as that used by its clients without affecting the server's ability to securely communicate with the rest of the domain hierarchy.

Designing a Domain Hierarchy

If you are unfamiliar with domain hierarchies, first read Chapter 2, NIS+: An Introduction. It describes NIS+ domain structure, information storage, and security.

After you are familiar with the components of a domain hierarchy, make a diagram of how you expect the hierarchy to look when you are finished. The diagram will be a useful reference when you are in the midst of the setup procedure. At a minimum, you will need to consider the following issues:

• Organizational or geographical mapping

• Connection to higher domain.

• Client support in the root domain.

• Domain size compared to number of domains.

• Number of levels.

• Security levels.

• Replicas and number of replicas.

• Information management.

Remember that a domain is not an object, but a reference to a collection of objects. Therefore, a server that supports a domain is not actually associated with the domain but with the domain's directories. A domain consists of four directories: domain, ctx_dir.domain, org_dir.domain, and groups_dir.domain, as shown below.

Figure 26–3 Server Relationship to Domain

Organizational or Geographical Mapping

One of the major benefits of NIS+ is its capability of dividing the namespace into smaller, more manageable parts. You could create a hierarchy of organizations, such as those of the hypothetical corporation, Doc Inc., as shown below.

Figure 26–4 Sample NIS+ Hierarchy by Logical Organization

You could also organize the hierarchy by buildings instead of organizations, as shown below.

Figure 26–5 Sample NIS+ Hierarchy by Physical Location

The scheme you select depends primarily on how you prefer to administer the namespace and how clients will tend to use the namespace. For example, if clients of factory.com. will be distributed throughout the buildings of Doc Inc., you should not organize the namespace by building. Because the clients constantly need to have access to other domains, you need to add their credentials to the other domains and you increase traffic flow through the root master server. A better scheme would be to arrange clients by organization. On the other hand, building-sized domains are immune to the reorganizations that require organization-based domains to be restructured.

Do not be limited by the physical layout of the network; an NIS+ namespace does not have to be congruent with the physical network, except where it has to support NIS clients. The number of domains your namespace needs depends on the kind of hierarchy you select.

Consider future expansion plans. Will today's NIS+ root domain be beneath another NIS+ domain in the future? Changing this arrangement would entail a great deal of work. Try to estimate the need for future domains in the namespace and design a structure that can accommodate them without disruption.

Connection to Higher Domains?

Consider whether the NIS+ namespace will be connected to higher domains, such as those of the Internet or DNS. If you currently use NIS under a DNS hierarchy, do you want to replace only the NIS domains or do you want to replace the entire company-wide DNS/NIS structure with an NIS+ namespace?

Client Support in the Root Domain

In the two Doc Inc., domain hierarchies illustrated in Figure 26–4 and Figure 26–5, are all the clients placed in domains beneath the root domain? Or do some belong to the root domain? Is the purpose of the root domain to act only as the root for its subdomains, or will it support its own group of clients? You could place all clients in the lowest layer of domains, and only those used for administration in the root and any intermediate domains. For example, if you implemented the plan in Figure 26–4, all clients would belong to the big.sales.com., small.sales.com., and factory.com. domains, and only clients used for administration would belong to the .com. and sales.com. domains.

Or you could place the clients of general-purpose departments in higher-level domains. For example, in Figure 26–5, where the domain is organized by building, you could put the clients of the Facilities Department in the .com. domain. It is not recommended that you do so, however, because the root domain should be kept simple and relatively unpopulated.

Domain Size Compared With Number of Domains

The current NIS+ implementation is optimized for up to 1000 NIS+ clients per domain and for up to 10 replicas per domain. Such a domain would typically have 10,000 table entries. The limitations come from the current server discovery protocol. If you have more than 1000 NIS+ clients, you should divide your namespace into different domains and create a hierarchy.

Creating a hierarchy, however, may introduce more complexity than you are prepared to handle. You may still prefer to create larger domains rather than a hierarchy; because one large domain requires less administration than multiple smaller domains. Larger domains need fewer skilled administrators to service them, since tasks can be automated more readily (with scripts you create), thus lowering the administrative expense. Smaller domains provide better performance, and you can customize their tables more easily. You also achieve greater administrative flexibility with smaller domains.

Number of Levels

NIS+ was designed to handle multiple levels of domains. Although the software can accommodate almost any number of levels, a hierarchy with too many levels is difficult to administer. For example, the names of objects can become long and unwieldy. Consider 20 to be the limit for the number of subdomains for any one domain and limit the levels of the NIS+ hierarchy to 5.

Security Level

Typically, you will run the namespace at security level 2. However, if you plan to use different security levels for different domains, you should identify them now. Understanding the Impact of NIS+ Security provides more information about security levels.

Domains Across Time Zones

Geographically-dispersed organizations may determine that organizing their domain hierarchy by functional groups causes a domain to span more than one time zone. It is strongly recommended that you do not have domains that span multiple time zones. If you do need to configure a domain across time zones, be aware that a replica's time is taken from the master server, so the database updates will be synchronized properly, using Greenwich mean time (GMT). This may cause problems if the replica machine is used for other services that are time critical. To make domains across time zones work, the replica's /etc/TIMEZONE file has to be set locally to the master server's time zone when you are installing NIS+. After the replica is running, some time-critical programs may run properly and some may not, depending on whether these programs use universal or local time.

Information Management

It is best to use a model of local administration within centralized constraints for managing the information in an NIS+ namespace. Information should be managed, as much as possible, from within its home domain, but according to guidelines or policies set at the global namespace level. This provides the greatest degree of domain independence while maintaining consistency across domains.

Domain Names

Consider name length and complexity. First, choose names that are descriptive. For example, “Sales” is considerably more descriptive than “BW23A.” Second, choose short names. To make your administrative work easier, avoid long names such as administration_services.corporate_headquarters.doc.com.

A domain name is formed from left to right, starting with the local domain and ending with the root domain. The root domain must always have at least two labels and must end in a dot. The second label can be an Internet domain name, such as “com.”

Also consider implications of particular names for email domains, both within the company and over the Internet.

Depending on the migration strategy, a viable alternative is to change domain names on NIS to the desired structure, then migrate to NIS+ domain by domain.

Email Environment

Because NIS+ can have a domain hierarchy while NIS has a flat domain space, changing to NIS+ can have effects on your mail environment. With NIS, only one mail host is required. If you use a domain hierarchy for NIS+, you may need one mail host for each domain in the namespace because names in separate domains may be no longer unique.

Therefore, the email addresses of clients who are not in the root domain may change. As a general rule, client email addresses can change when domain names change or when new levels are added to the hierarchy.

In earlier Solaris releases, these changes required a great deal of work. This release provided several sendmail enhancements to make the task easier. In addition, NIS+ provides a sendmailvars table. The sendmail program first looks at the sendmailvars table (see Figure 26–7, then examines the local sendmail.cf file.

Be sure that mail servers reside in the NIS+ domain whose clients they support. For performance reasons, do not use paths to direct mail servers to tables in other domains.

Consider the impact of the new mail addresses on DNS. You may need to adjust the DNS MX records.

Determining Server Requirements

Each NIS+ domain is supported by a set of NIS+ servers. Each set contains one master and one or more replica servers. These servers store the domain's directories, groups, and tables, and answer requests for access from users, administrators, and applications. Each domain is supported by only one set of servers. While a single set of servers can support more than one domain, this is not recommended.

The NIS+ service requires you to assign at least one server, the master, to each NIS+ domain. How many replica servers a domain requires is determined by the traffic load, the network configuration, and whether NIS clients are present. The amount of server memory, disk storage, and processor speed is determined by the number of clients and the traffic load they place on the servers.

Any machine, running in the Solaris operating environment, can be an NIS+ server, as long as it has its own hard disk of sufficient size. The software for both NIS+ servers and clients is included in the Solaris product. Therefore, any machine that has the Solaris operating environment installed can become a server or a client, or both.

When determining what servers are needed to support your NIS+ namespace, consider these factors, discussed in the following sections.

Number of Supported Domains

To begin, you assign one master server to each domain in the hierarchy.The following figure shows one possible assignment.

Figure 26–6 Assigning Servers to Domains

Add one or more replicas to each domain. Replicas allow requests to be answered even if the master server is temporarily out of service. (See Number of Replica Servers for information on how many replicas to use.)

Figure 26–7 Adding Replicas to a Domain

Number of Replica Servers

The optimum number of servers (master plus replicas) for a domain is determined by a number of factors:

• NIS+ master servers require fewer replicas than NIS servers, since NIS+ does not depend on broadcasts on the local subnet.

• Every domain should have at least one replica server so that NIS+ service is not disrupted when the master server is temporarily unavailable.

• No domain should have more than 10 replicas. This is because of the increased network traffic and server load when information updates are propagated to many replicas.

• The type of clients. Older, slower client machines require fewer replicas than do newer, faster machines.

• If the domain hierarchy that you design spans a wide area network (WAN) link, it is prudent to place a replica on either side of the WAN link. In other words, have a master server and one or more replicas on one side of the link and one or more replicas on the other side. This could possibly enable clients on the other side of the link to continue with NIS+ service even if the WAN link were temporarily disabled. (Putting servers on either side of a WAN, however, does change the structure of a namespace that is organized by group function rather than by physical layout, since the replica might physically reside within the geographic perimeter of a different domain.)

  In organizations with many distributed sites, each site often needs its own subdomain. The subdomain master is placed in a higher-level domain. As a result, there can be a great deal of traffic between point-to-point links. Creating local replicas can speed request response and minimize point-to-point traffic across the link. In this configuration, lookups may be handled locally.

• The number of subnets in a domain. If you can, put one replica on each subnet (but do not use more than 10 replicas for the entire domain). Note that you do not have to have a replica for every subnet unless you have Solaris 1.x NIS clients and you want NIS+ servers in NIS-compatibility mode to support the NIS clients. NIS clients do not have access to servers that are not on the same subnet. The only exceptions are Solaris NIS clients, which can use ypinit(1M) to specify a list of NIS servers. The netmask number in these cases would have to be set appropriately.

• How users and administrators perform lookups. A niscat table | grep name command uses far more server resources than does a nismatch name tablecommand.

• The type of server. Newer, faster servers provide quicker, more efficient service than do older, slower machines. Thus, the more powerful your servers, the fewer of them you need.

• Number of clients. The more clients you have in a domain, the more replica servers you need. Try to keep fewer than 1000 clients in a domain. NIS+ clients present a higher load on servers than NIS clients. A large number of clients served by only a few servers can impact network performance.

  The table below summarizes the peak number of busy clients that a set of servers can handle without any slowing of response time. In the benchmark tests that produced these results, the clients were designed to make intensive use of NIS+ services. Each client made many NIS+ calls to simulate a peak load, rather than the average load experienced by normal production domains. Thus, the numbers shown in in the table below, illustrate configurations designed to meet peak load (as opposed to average load) without any slowing of response time.

  Table 26–1 Server Configurations and Number of NIS+ Clients

  Server and Replica Configuration	Peak Number of "Busy" Clients
  Master: SS5-110	120
  Master: SS5-110 Replica: SS10-40	220
  Master: SS5-110 Replica: SS10-40 Replica: SS20-50	580
  Master: Ultra-167	420
  Master: Ultra-167 Replica: SS10-40	840

  These numbers indicate that if your clients make extensive use of NIS+ services, you should add an extra replica for approximately every 100–400 clients. If your replicas are SS5s, you should add a new replica for every 100 clients; if your replicas are Ultras, you should add a new replica for every 400 clients. You should adjust these figures according to your needs.

One way you can have a sufficient number of replicas per domain without using a multiplicity of machines is to create multihomed servers. A multihomed server is a machine with multiple ethernet or network interfaces. A multihomed server can serve multiple subnets in a domain. (While it is possible to have a master or replica serve multiple domains, that is not recommended.)

Server Speed

The faster the server, the better NIS+ performs. (However, at this time NIS+ servers cannot take advantage of SMP multithreaded hardware.) Your NIS+ servers should be as powerful, or more powerful, than your average client. Using older machines as servers for newer clients is not recommended.

In addition to server speed, many other factors affect NIS+ performance. The numbers and kinds of users and hosts, the kinds of applications being run, network topology, load densities, and other factors, all affect NIS+ performance. Thus, no two networks can expect identical performance from the same server hardware.

The benchmark figures presented in the table below, are for comparison purposes only; performance on your network may vary. These benchmark figures are based on a test network with typical table sizes of 10,000 entries.

Server Memory Requirements

Although 32 Mbytes is the absolute minimum memory requirement for servers, it is better to equip servers of medium-to-large domains with at least 64 Mbytes.

Ideally, an NIS+ server should have enough memory to hold all the entries of all the searchable columns of all the operative NIS+ tables in RAM at one time. In other words, optimal server memory is equal to the total memory requirements of all the NIS+ tables.

For illustration purposes, the table below shows memory requirements for the netgroup table with five searchable columns, and Table 26–4 shows the approximate memory requirements for the passwd, t, and cred tables.

For the other tables, you can estimate the memory size by multiplying the estimated number of entries times the average number of bytes per entry for each searchable column. For example, suppose you have a table with 10,000 entries and two searchable columns. The average number of bytes per entry in the first column is 9, the average number of bytes per entry in the second column is 37. Your calculation is: (10,000x9)+(10,000x37)=460,000.

When estimating the number of entries in the cred table, keep in mind that every user will have two entries (one for the user's Local credential and one for the user's DES credential). Each machine will have only one entry.

See NIS+ Standard Tables for the number of searchable columns in each of the standard NIS+ tables.

Server Disk Space Requirements

How much disk space you need depends on four factors:

• Disk space consumed by the Solaris operating environment.

• Disk space for /var/nis (and /var/yp if using NIS compatibility).

• Amount of server memory.

• Swap space required for NIS+ server processes.

The Solaris operating environment can require over 220 Mbytes of disk space, depending on how much of it you install. For exact numbers, see your Solaris installation guides. You should also count the disk space consumed by other software the server might use. The NIS+ software itself is part of the Solaris operating environment distribution, so it does not consume additional disk space.

NIS+ directories, groups, tables, and client information are stored in /var/nis. The /var/nis directory uses about 5 Kbytes of disk space per client. For example purposes only, if a namespace has 1000 clients, /var/nis requires about 5 Mbytes of disk space. However, because transaction logs (also kept in /var/nis) can grow large, you may want additional space per client—an additional 10–15 Mbytes is recommended. In other words, for 1000 clients, allocate 15 to 20 Mbytes for /var/nis. You can reduce this if you checkpoint transaction logs regularly. You should also create a separate partition for /var/nis. This separate partition will help during an operating system upgrade.

If you will use NIS+ concurrently with NIS, allocate space equal to the amount you are allocating to /var/nis for /var/yp to hold the NIS maps that you transfer from NIS.

You also need swap space equal to twice the size of rpc.nisd—in addition to the server's normal swap space requirements. To see the amount of memory being used by rpc.nisd on your system, run the nisstat command. See the rpc.nisd man page for more information. Most of this space is used during callback operations or when directories are checkpointed (with nisping -C) or replicated, because during such procedures, an entire NIS+ server process is forked. In no case should you use less than 64 Mbytes of swap space.

Determining Table Configurations

NIS+ tables provide several features not found in simple text files or maps. They have a column-entry structure, accept search paths, can be linked together, and can be configured in several different ways. You can also create your own custom NIS+ tables. When selecting the table configurations for your domains, consider the following factors discussed in the following sections:

Differences Between NIS+ Tables and NIS Maps

NIS+ tables differ from NIS maps in many ways, but two of those differences should be kept in mind during your namespace design:

• NIS+ uses fewer standard tables than NIS.

• NIS+ tables interoperate with /etc files differently than NIS maps did in the SunOS 4.x releases.

NIS+ Standard Tables

Review the 17 standard NIS+ tables to make sure they suit the needs of your site. They are listed in NIS+ Standard Tables. Table 26–6 lists the correspondences between NIS maps and NIS+ tables.

Do not worry about synchronizing related tables. The NIS+ tables store essentially the same information as NIS maps, but they consolidate similar information into a single table (for example, the NIS+ hosts table stores the same information as the hosts.byaddr and hosts.byname NIS maps). Instead of the key-value pairs used in NIS maps, NIS+ tables use columns and rows. (See Table 26–6.) Key-value tables have two columns, with the first column being the key and the second column being the value. Therefore, when you update any information, such as host information, you need only update it in one place, such as the hosts table. You no longer have to worry about keeping that information consistent across related maps.

Note the new names of the automounter tables:

• auto_home (old name: auto.home)

• auto_master (old name: auto.master)

The dots were changed to underscores because NIS+ uses dots to separate directories. Dots in a table name can cause NIS+ to mistranslate names. For the same reason, machine names cannot contain any dots. You must change any machine name that contains a dot to something else. For example, a machine named sales.alpha is not allowed. You could change it to sales_alpha or salesalpha or any other name that does not contain a dot.

To make the transition from NIS to NIS+, you must change the dots in your NIS automounter maps to underscores. You may also need to do this on your clients' automounter configuration files. Refer to the following table:

NIS+ has one new table for which there is no corresponding NIS table: sendmailvars. The sendmailvars table stores the mail domain used by sendmail.

NIS+ Tables Interoperate Differently With /etc Files

The manner in which NIS and other network information services interacted with /etc files in the SunOS 4.x environment was controlled by the /etc files using the +/- syntax. How NIS+, NIS, DNS and other network information services interact with /etc files in the Solaris operating environment is determined by the name service switch. The switch is a configuration file, /etc/nsswitch.conf, located on every Solaris operating environment client. It specifies the sources of information for that client: /etc files, DNS zone files (hosts only), NIS maps, or NIS+ tables. The nsswitch.conf configuration file of NIS+ clients resembles the simplified version in the following example.

Example 26–1 Simplified Name Service Switch File

passwd: files

group: compat

group_compat: nisplus

hosts: nisplus dns [NOTFOUND=return] files

services: nisplus [NOTFOUND=return] files

networks: nisplus [NOTFOUND=return] files

protocols: nisplus [NOTFOUND=return] files

rpc: nisplus [NOTFOUND=return] files

ethers: nisplus [NOTFOUND=return] files

netmasks: nisplus [NOTFOUND=return] files

bootparams: nisplus [NOTFOUND=return] files

publickey: nisplus

netgroup: nisplus

automount: files nisplus

aliases: files nisplus

In other words, for most types of information, the source is first an NIS+ table, then an /etc file. For the passwd and group entries, the sources can either be network files or from /etc files and NIS+ tables as indicated by +/- entries in the files.

You can select from three versions of the switch-configuration file or you can create your own. For instructions, see Chapter 1, The Name Service Switch.

Use of Custom NIS+ Tables

Determine which nonstandard NIS maps you use and their purpose. Can they be converted to NIS+ or replaced with NIS+ standard maps?

Some applications may rely on NIS maps. Will they still function the same way with NIS+, and can they function correctly in a mixed environment?

To build a custom table in NIS+, use nistbladm. Remember that you cannot use dots in the table names.

If you want to use NIS+ to support your custom NIS maps, you should create a key-value table, a table with two columns. The first column is the key and the second column is the value. If you then run the NIS+ servers in NIS-compatibility mode, the NIS clients will not notice any change in functionality.

Connections Between Tables

NIS+ tables contain information only about the resources and services in their home domain. If a client tries to find information that is stored in another domain, the client has to provide the other domain name. You can make this “forwarding” automatic by connecting the local table to the remote table. NIS+ tables can be connected in two different ways:

• Through paths.

• Through links.

Do not use paths and links if you are going to have NIS clients in the NIS+ namespace, because NIS clients are unable to follow the paths or links to find the appropriate information.

Paths

If information in a particular NIS+ table is often requested by clients in other domains, consider establishing a path from the local NIS+ table to the one in the other domain. Refer to the following figure:

Figure 26–8 Establishing a Path to Tables in a Higher Domain

Such a path has two main benefits. First, it saves clients in lower domains the trouble of explicitly searching through a second table. Second, it allows the administrator in the higher-level domain to make changes in one table and render that change visible to clients in other domains. However, such a path can also hurt performance. Performance is especially affected when searches are unsuccessful, because the NIS+ service must search through two tables instead of one. When you use paths, a table lookup now also depends upon the availability of other domains. This dependence can reduce the net availability of your domain. For these reasons, use paths only if you do not have any other solution to your problem.

You should also be aware that since “mailhost” is often used as an alias, when trying to find information about a specific mail host, you should use its fully qualified name in the search path (for example, mailhost.sales.com.); otherwise NIS+ will return all the “mailhosts” it finds in all the domains it searches through.

The path is established in the local table, with the -p option to the nistbladm command. To change a table's path, you must have modify access to the table object. To find a table's search path, use the niscat -o command (you must have read access to the table).

Links

Links between tables produce an effect similar to paths, except that the link involves a search through only one table: the remote table. With a search path, NIS+ first searches the local table, and only if it is unsuccessful does it search the remote table. With a link, the search moves directly to the remote table. In fact, the remote table virtually replaces the local table. The benefit of a link is that it allows a lower domain to access the information in a higher domain without the need to administer its own table.

To create a link, use the nisln command. You must have modify rights to the table object.

Deciding whether to use a path or to link NIS+ tables in a domain is a complex decision, but here are some basic principles:

• Every domain must have access to every standard table.

• Volatile, frequently accessed data should be located lower in the hierarchy. Such data should be located closer to where it is used most often.

• Data that is accessed by several domains should be located higher in the hierarchy, unless the domains need to be independent.

• The lower in the hierarchy you place data, the easier it is to administer autonomously.

• Only NIS+ clients can see tables connected by paths and links. They cannot be seen by NIS clients, as illustrated by the following figure:

Figure 26–9 Information Distribution Across an NIS+ Hierarchy

Resolving User/Host Name Conflicts

NIS+ cannot distinguish between a human principal and a machine principal when requests are made. Therefore, all user names must be different from machine names in the same namespace. In other words, within a given namespace, no user can have the same user name as a machine name, and no machine can have the same name as any user ID.

For example, under NIS it was acceptable to have a user with the login name of irina whose local machine is also named irina. Her network address would be irina@irina. This is not allowed under NIS+. When the site is converted to NIS+, either the user will have to change her login name or her machine name. Identical user and machine names are a problem even when the machine with the duplicate name does not belong to the user with the same name. The following examples illustrate duplicate name combinations not valid with NIS+:

• jane@jane in the same namespace

• patna@peshawar and rani@patna in the same namespace

The best solution to this problem is to check all /etc files and NIS maps before you use the data to populate NIS+ tables. If you find duplicate names, change the machine names rather than the login names, and later create an alias for the machine's old name.

Understanding the Impact of NIS+ Security

Because NIS+ provides security that NIS did not, it requires more administrative work. It may also require more work from users who are not accustomed to performing chkey, keylogin, or keylogout procedures. Furthermore, the protection provided by NIS+ is not entirely secure. Given enough computing power and the right knowledge, the Diffie-Hellman public-key cryptography system can be broken.

Using Diffie-Hellman keys longer than 192 bits significantly increases NIS+ security. You might, however, experience a degradation in performance as the longer key length requires more time to authenticate.

Use nisauthconf to configure the type of Diffie-Hellman key. See nisauthconf(1M) for information about using longer keys.

In addition, the secret key stored with the key server process is not automatically removed when a credentialed nonroot user logs out unless that user logs out with keylogout(1). Security may be compromised even if the user logs out with keylogout(1) because the session keys may remain valid until they expire or are refreshed. (See keylogout(1) for more information.) Root's key, created by keylogin -r and stored in /etc/.rootkey, remains until the .rootkey file is explicitly removed. The superuser cannot use keylogout. Nevertheless, NIS+ is much more secure than NIS.

How NIS+ Security Affects Users

NIS+ security benefits users because it improves the reliability of the information they obtain from NIS+ and it protects their information from unauthorized access. However, NIS+ security requires users to learn about security and requires them to perform a few extra administrative steps.

Although NIS+ requires a network login, users are not required to perform an additional key login because the login command automatically gets the network keys for the client when the client has been correctly configured. Clients are correctly configured when their login password and their Secure RPC password are the same. The secret key for the user root is normally made available in the /etc/.rootkey file (with a possible security problem, as noted earlier). When the NIS+ user password and credential are changed with the passwd command, the credential information is automatically changed for the user.

• To change the NIS+ machine's local root password, run the passwd command.

• To change the root credential, run the chkey command.

However, if your site allows users to maintain passwords in their local /etc/passwd files in addition to their Secure RPC passwords, and if these passwords are different from the Secure RPC passwords, then users must run keylogin each time they run login.

How NIS+ Security Affects Administrators

Because the Solaris operating environment includes the DES encryption mechanism for authentication, administrators who require secure operation do not need to purchase a separate encryption kit. However, administrators must train users how to use the passwd and the passwd -r commands, and when to use them.

Furthermore, setting up a secure NIS+ namespace is more complex than setting up a namespace without any security. The complexity comes not only from the extra steps required to set up the namespace, but from the job of creating and maintaining user and machine credentials for all NIS+ principals. Administrators have to remove obsolete credentials just as they remove inactive account information from the passwd and hosts tables. Also, when servers' public keys change, administrators have to update the keys throughout the namespace (using nisupdkeys). Administrators also have to add LOCAL credentials for users from other domains who want to remote login to this domain and have authenticated access to NIS+.

How NIS+ Security Affects Transition Planning

After you become familiar with the benefits and the administrative requirements of NIS+ security, you must decide whether to implement NIS+ security during or after the transition. It is recommended that you use full NIS+ security even if you operate some or all servers in a domain in NIS-compatibility mode. (All servers in a domain should have the same NIS-compatibility status.) However, this entails a heavy administrative burden. If you prefer a simpler approach, you could set up the NIS+ servers and namespace with NIS-compatible security, but decline to create credentials for NIS+ clients. Administrators and servers would still require credentials. The NIS+ clients would be relegated to the nobody class, along with the NIS clients. This reduces training and setup requirements, but it has the following drawbacks:

• Users lose the ability to update any NIS+ tables, but they retain their ability to change their login password. (Solaris 2.5 through Solaris 9 only.)

• Users are not able to verify that the name service information is coming from an authenticated NIS+ server.

Selecting Credentials

NIS+ provides two types of credential: LOCAL and DES.

In this manual, the term, DES credentials, applies to the extended 640–bit Diffie-Hellman keys as well as to the original 192–bit Diffie-Hellman (default) key length. In the cred table, the extended keys use designations such as DH640-0, rather than the DES keyword. See nisauthconf(1M) for information about using longer keys.

All NIS+ principals need at least one of these credentials. When the namespace is running at security level 2 (the default), all NIS+ principals (clients) must have DES credentials in their home domains. In addition, all users (not machines) must have LOCAL credentials in their home domains and in every other domain for which they need login access.

To determine the credential needs of your namespace, consider the:

• Type of principal

• Type of credential

NIS+ principals can be users or the superuser identity on the client machine. See Figure 26–10.

Figure 26–10 NIS+ Principals

When you determine the credentials you need to create, make sure you know which type of principal needs the credential. For instance, when you set up an NIS+ client with the nisclient script, you create credentials for both the machine and for the user. Unless credentials for the user are also created, the user only has the access rights granted to the nobody class. This can work very well. But if you don't give any access rights to the nobody class, the namespace won't be available to users.

Choosing a Security Level

NIS+ is designed to be run at security level 2, which is the default. Security levels 0 and 1 are provided only for the purposes of testing and debugging. Do not run an operational network with real users at any level other than level 2. See Chapter 11, NIS+ Security Overview for more information.

Establishing Password-aging Criteria, Principles, and Rules

Password-aging is a mechanism that you can use to force users to periodically change their passwords. Password-aging allows you to:

• Specify the maximum number of days that a password can be used before it has to be changed.

• Specify the minimum number of days that a password has to be in existence before it can be changed.

• Specify a warning message to be displayed whenever a user logs in a specified number of days before the user's password time limit is reached.

• Specify the maximum number of days that an account can be inactive. If that number of days pass without the user logging in to the account, the user's password is locked.

Keep in mind that users who are already logged in when the various maximums or dates are reached are not affected by the above features. They can continue to work as normal. Password-aging limitations and activities are activated only when a user logs in or performs one of the following operations:

• login

• rlogin

• telnet

• ftp

These password-aging parameters are applied on a user-by-user basis; you can have different password-aging requirements for different users. You can also set general default password-aging parameters that apply to all users except those you have individually set.

When planning your NIS+ namespace, decide which password-aging features you want to implement, and the default values you want to specify. For additional information on password-aging, see Chapter 16, Administering Passwords.

Planning NIS+ Groups

NIS+ introduces a new type of group to name service administration, which NIS does not have. An NIS+ group is used only as a means to provide NIS+ access rights to several NIS+ principals at one time; it is used only for NIS+ authorization.

An NIS+ group is one of the four authorization classes on which access rights are based. The four classes are:

• Owner. Every NIS+ object has one owner who is a single user. The owner is usually the person who created the object, but ownership can be transferred to another user.

• Group. A collection of users grouped together under a group name for the purpose of granting that collection of users specified NIS+ access rights.

• World. All authenticated users. In other words, any user with valid DES credentials. By definition, an object's owner and members of an object's group are also part of the world class so long as their credentials are valid.

• Nobody. Anyone who does not have a valid DES credential. If the credentials of some member of one of the other classes are invalid or missing or corrupted or not found, then that user is placed in the nobody class.

The default name of the group created by NIS+ scripts for such purposes is the admin group. You can create other groups with different names, and assign different groups to different NIS+ objects.

Member users of an object's group usually have special privileges to access that object, such as permission to make certain changes to the object. For example, you could add several junior administrators to the admin group so that they can only modify the passwd and hosts tables, but they would be unable to modify any other tables. By using an admin group, you can distribute administration tasks across many users and not just reserve them for the superuser of the entire hierarchy. The NIS+ admin group must have credentials created for its members, even if you are running the domain in NIS-compatibility mode, because only authenticated users have permission to modify NIS+ tables.

After identifying the type of credentials you need, you should select the access rights that are required in the namespace. To make that task easier, you should first decide how many administrative groups you need. Using separate groups is useful when you want to assign them different rights. Usually, you create groups by domain. Each domain should have only one admin group.

Planning Access Rights to NIS+ Groups and Directories

After arranging your principals into groups, determine the kinds of access rights granted by the objects in the namespace to those groups, as well as to the other classes of principal (nobody, owner, group, and world). Planning these assignments ahead of time will help you establish a coherent security policy.

As shown in Table 26–7, NIS+ provides different default access rights for different namespace objects.

You can use the default rights or assign your own. If you assign your own, you must consider how the objects in your namespace will be accessed. Keep in mind that the nobody class accepts all requests from NIS+ clients, whether authenticated or not. The world class comprises all authenticated requests from NIS+ clients. Therefore, if you don't want to provide namespace access to unauthenticated requests, don't assign any access rights to the nobody class; reserve them only for the world class. On the other hand, if you expect some clients—through applications, for instance—to make unauthenticated read requests, you should assign read rights to the nobody class. If you want to support NIS clients in NIS-compatibility mode, you must assign read rights to the nobody class.

Also consider the rights that each type of namespace object assigns to the NIS+ groups you specified earlier. Depending on how you plan to administer the namespace, you can assign all or some of the available access rights to the group. A good solution is to have the user root on the master server be the owner of the admin group. The admin group should have create and destroy rights on the objects in the root domain. If you want only one administrator to create and modify the root domain, then put just that administrator in the admin group. You can always add additional members to the group. If several administrators are involved in the setup process, put them all in the group and assign full rights to it. That is easier than switching ownership back and forth.

Finally, the owner of an object should have full rights, although this is not as important if the group does. A namespace is more secure if you give only the owner full rights, but it is easier to administer if you give the administrative group full rights.

Planning Access Rights to NIS+ Tables

NIS+ objects other than NIS+ tables are primarily structural. NIS+ tables, however, are a different kind of object: they are informational. Access to NIS+ tables is required by all NIS+ principals and applications running on behalf of those principals. Therefore, their access requirements are a somewhat different.

Table 26–8 lists the default access rights assigned to NIS+ tables. If any columns provide rights in addition to those of the table, they are also listed. You can change these rights at the table and entry level with the nischmod command, and at the column level with the nistbladm -u command. Protecting the Encrypted Passwd Field provides just one example of how to change table rights to accommodate different needs.

NIS-compatible domains give the nobody class read rights to the passwd table at the table level.

Protecting the Encrypted Passwd Field

As you can see in Table 26–8, default read access is provided to the nobody class by all tables except the passwd table. NIS+ tables give the nobody class read access because many applications that need to access NIS+ tables run as unauthenticated clients. However, if this were also done for the passwd table, it would expose the encrypted passwd column to unauthenticated clients.

The configuration shown in Table 26–8 is the default set of access rights for NIS-compatible domains. NIS-compatible domains must give the nobody class read access to the passwd column because NIS clients are unauthenticated and would otherwise be unable to access their passwd column. Therefore, in an NIS-compatible domain, even though passwords are encrypted, they are vulnerable to decoding. They would be much more secure if they were not readable by anyone except their owner.

Standard NIS+ domains (not NIS-compatible) provide that extra level of security. The default configuration (provided by nissetup) uses a column-based scheme to hide the passwd column from unauthenticated users, while still providing access to the rest of the passwd table. At the table level, no unauthenticated principals have read access. At the column level, they have read access to every column except the passwd column.

How does an entry owner get access to the passwd column? Entry owners have both read and modify access to their own entries. They obtain read access by being a member of the world class. (Remember that at the table level, the world class has read rights.) They obtain modify access by explicit assignment at the column level.

Keep in mind that table owners and entry owners are rarely and not necessarily the same NIS+ principals. Thus, table-level read access for the owner does not imply read access for the owner of any particular entry.

As mentioned earlier, this is the default setup from the Solaris 2.3 release through Solaris 9. For a more complete explanation and discussion of table-, entry-, and column level-security, see Chapter 16, Administering Passwords.

Using NIS Compatibility Mode: An Introduction

Deciding whether and how to run NIS+ in parallel to NIS—and when to stop—is probably one of the most difficult transition issues you will face. NIS+ provides several features that allow it to operate in parallel with NIS, notably, the NIS-compatibility mode.

If you plan to use NIS-compatibility mode, you have to consider the essential benefit provided by NIS-compatibility mode. You need not make any changes to NIS clients. The essential drawback is that you cannot take advantage of full NIS+ security and hierarchy and you may have to change those clients' domain names.

Figure 26–11 illustrates how you convert from an NIS-only namespace to an NIS-compatible namespace that responds to both NIS and NIS+ requests.

Figure 26–11 Transition to NIS-Compatibility Mode

Selecting Your NIS-Compatible Domains

Make a list of your NIS clients and group them in their eventual NIS+ domains. If the NIS+ domain running in NIS-compatibility mode does not have the same name as its NIS clients' original NIS domain, you must change the NIS clients' domain name to the NIS+ domain name that is being supported by the NIS-compatible NIS+ server.

At first, NIS will no doubt be the primary service. As you become familiar with the intricacies of sharing information, you can plan a transition to make NIS+ the primary service. Some NIS+ users may want the capability of switching back and forth between the main NIS domain and the new NIS+ domain. The nisclient script can help them do this when backup files are made.

Determining NIS-Compatible Server Configuration

Take stock of your NIS servers, keeping in mind the requirements for your NIS+ servers. If you plan to eventually use them for the NIS+ service, upgrade them to the NIS+ recommendations. Identify which NIS servers will be used to support which NIS+ domains, and in what capacity (either master or replica). Remember that NIS+ servers belong to the domain above the one they support (except for the root domain servers). Since NIS+ servers do not belong to the domain they serve, you cannot use the same machines for other services that require domain-dependent information.

If possible, plan to use your NIS+ server machines only for NIS+. This arrangement can require you to transfer other network services, such as DNS name services, boot server, home directories, NFS servers, and so on, to non-NIS+ server machines.

At many sites, the NIS server plays multiple roles, such as NFS server, compute server, rlogin server, and mail host server. Because the NIS server uses the same information to resolve its names as do its clients, the NIS server can provide other services as well. As discussed in Domain Hierarchy, except for root domains, all NIS+ servers live in the domain above the ones that they serve. So either do not run services on an NIS+ server that require access to the name service, or use other means, such as files in nsswitch.conf, to acquire this same information. This problem would be solved if there were no hierarchy; the NIS+ root servers would live in the domain that they serve. The resource requirements of an NIS+ server are greater than those of an NIS server; therefore, it is advisable to avoid running other services along with NIS+.

If you have non-Solaris machines on your network, then you can either continue to run your NIS+ servers in NIS-compatibility mode or you can move all such machines into their own domain. If you move all non-Solaris machines to one subnet, you can remove the restriction of having NIS+ servers on the same subnet as their NIS-compatible clients. This will reduce the number of replicas required for any domain.

Deciding How to Transfer Information Between Services

To keep information synchronized, be sure to make one namespace subordinate to the other. At first, the NIS namespace may be the dominant one, in which case you would make changes to the NIS maps and load them into the NIS+ tables. In effect, the NIS namespace would be the master database.

An NIS+ server in NIS-compatibility mode supports standard NIS maps. An exhaustive list of these maps is in the Notes section of the ypfiles(4) man page. However, there are some limitations on map support: The NIS+ server serves ypmatch requests only on the netgroup map, and not on the reverse maps. It does not support enumeration requests on the netgroup map (for example, ypcat). The passwd.adjunct map is not supported, either.

Eventually, the NIS+ namespace should be dominant. When that is the case, you make changes in the NIS+ tables and copy them to the NIS maps.

The NIS+ nisaddent command and the NIS+ nispopulate script transfer information between NIS maps and NIS+ tables, as summarized in Table 26–9.

In versions of NIS+ previous to the Solaris 2.5 release, it was necessary to use separate password commands (passwd, yppasswd, nispasswd) to handle password matters, depending on whether a user's password information was stored in /etc files, NIS maps, or NIS+ tables. Starting with the Solaris 2.5 release, all of these matters are handled automatically by the passwd or passwd -r nisplus commands and are controlled by the passwd entry in the user's nsswitch.conf file.

In order to properly implement the passwd command and password aging on your NIS+ or NIS-compatible network, the passwd entry of the nsswitch.conf file on every machine must be correct. This entry determines where the passwd command goes for password information and where it updates password information.

Only five passwd entry configurations are permitted:

Example 26–2 Permitted passwd nsswitch.conf Entries

passwd:files
 
passwd: files nis
 
passwd: files nisplus
 
passwd: compat
 
passwd_compat: nisplus

All of the nsswitch.conf files on all of your network's machines must use one of the passwd configurations shown above. If you configure the passwd entry in any other way, users may not be able to log in.

In domains created with NIS-compatibility mode, the permissions are slightly different: permissions at the table level must be set to provide read rights to the world class, and at the column level, permissions must provide read access to the nobody class.

Deciding How to Implement DNS Forwarding

NIS servers can forward DNS requests made from Solaris 1.x NIS clients. NIS+ servers running in NIS-compatibility mode also provide DNS forwarding, starting with the Solaris 2.3 releases. (This feature is available in the Solaris 2.2 release patch #101022-06.) As a result, NIS clients, running under the Solaris 2 or Solaris 9 operating environment, must have appropriate /etc/nsswitch.conf and /etc/resolv.conf files installed locally.

Solaris 1.x NIS clients supported by Solaris 2.0 or 2.1 servers running in NIS-compatibility mode are not able to take advantage of DNS forwarding. You must upgrade those servers to Solaris 2.3 releases.

If the DNS domains are repartitioned, you must redefine new DNS zone files. Clients, however, may require updates to their /etc/resolv.conf file. A client, if it is also a DNS client, can set up its name service switch configuration file to search for host information in either DNS zone files or NIS maps—in addition to NIS+ tables.

DNS Forwarding for NIS+ Clients

NIS+ clients do not have implicit DNS-forwarding capabilities like NIS clients do. Instead, they take advantage of the name service switch. To provide DNS capabilities to an NIS+ client, change its hosts entry to:

hosts: nisplus dns [NOTFOUND=return] files

DNS Forwarding for NIS Clients Running under the Solaris 2 or Solaris 9 Operating Environment

If an NIS client is using the DNS forwarding capability of an NIS-compatible NIS+ server, the client's nsswitch.conf file should not have the following syntax in the hosts file:

hosts: nis dns files

Since DNS-forwarding automatically forwards host requests to DNS, this syntax causes both the NIS+ server and the name service switch to forward unsuccessful requests to the DNS servers, slowing performance.

NIS and NIS+ Command Equivalents in the Solaris 1, Solaris 2, and Solaris 9 Releases

The tables in this section give a quick overview of the differences between NIS commands running in the Solaris 1 operating environment, NIS commands running in the Solaris 2 or Solaris 9 operating environment, and their NIS+ equivalents.

• Table 26–10 describes which NIS commands are supported in the Solaris 2 and Solaris 9 releases.

• Table 26–11 and Table 26–12 describe the NIS+ equivalents to NIS client and server commands in the Solaris 2 and Solaris 9 releases.

• Table 26–13 contains a list of the NIS application programming interface functions and their NIS+ API equivalents, if they exist. See the appropriate man pages for details.

NIS Commands Supported in the Solaris 2 and Solaris 9 Releases

Only some NIS commands are supported in the Solaris 2 and Solaris 9 releases. NIS server commands are not shipped with the Solaris 2 and Solaris 9 releases. Only the NIS client commands are included. Whether these NIS commands run also depends on whether a Solaris 2 or Solaris 9 NIS client is making requests of an NIS server or of an NIS+ server in NIS-compatibility mode. NIS clients cannot make updates to NIS+ servers that are running in NIS-compatibility mode. For example, such clients cannot run the chkey and newkey commands. Table 26–10 lists the NIS commands supported in the Solaris 2 and Solaris 9 operating environments.

Client and Server Command Equivalents

The two tables in this section contain NIS commands and their approximate NIS+ equivalents. The commands have been divided into two categories: Table 26–11 contains name service client commands and Table 26–12 contains name service server commands.

Client Command Equivalents

Table 26–11 shows client-to-name server commands. These commands are typed on name service client machines and request information of name service servers. The commands in column 1 run on Solaris 1, Solaris 2 or Solaris 9 NIS clients connected to Solaris 1 NIS servers. The commands in column 2 run on Solaris 1, Solaris 2, or Solaris 9 NIS clients connected to Solaris 2 or Solaris 9 NIS+ servers running in NIS-compatibility mode. The commands in column 3 only run on Solaris 2 or Solaris 9 NIS+ clients connected to Solaris 2 or Solaris 9 NIS+ servers. Commands are approximately equivalent across rows. “N/A” indicates that an equivalent command does not exist for that case.

Note that:

• In the Solaris 2.5 release, the passwd command should be used regardless of NIS or NIS+ status. The functions previously performed by nispasswd and yppasswd have now been included in the passwd command.

• The ypinit -c command is available only on Solaris 2 or Solaris 9 NIS clients.

• The ypcat command is not supported for queries directed to the netgroup table. The NIS client's request times out before an answer is received because this table's format is so different from the netgroup NIS map's format.

Server Command Equivalents

Table 26–12 shows name server-to-name server commands. The NIS server commands are not included in the Solaris 2 or Solaris 9 releases, so they are not available to either NIS+ servers or NIS+ servers in NIS-compatibility mode. In addition, an NIS server cannot make updates to an NIS+ server, nor can an NIS+ server make updates to an NIS server. Column 3 lists the NIS+ server commands that are equivalent to the NIS server commands in column 1. Servers in NIS-compatibility mode have no exact equivalents because NIS-compatibility mode refers only to client commands.

NIS and NIS+ API Function Equivalents

To completely convert your site to NIS+, you must both change the name service and port all applications to NIS+. Any internally created applications that make NIS calls have to be modified to use NIS+ calls. Otherwise, you always have to run your NIS+ servers in NIS-compatibility mode, with all the drawbacks that this mode entails. External applications may force you to run your namespace in NIS-compatibility mode until they are updated, as well.

Table 26–13 contains a list of the NIS API functions and their NIS+ API equivalents, if they exist.

NIS-Compatibility Mode Protocol Support

Table 26–14 shows which NIS protocols are supported by NIS+ servers in NIS- compatibility mode.

Before You Transition to NIS+: Gauge the Impact of NIS+ on Other Systems

Develop a formal introduction, testing, and familiarization program for your site, not only to train administrators, but also to uncover dependencies of other systems or applications on NIS that will be affected by a transition to NIS+.

For example, some applications may rely on some of the NIS maps. Will they function with standard or custom NIS+ tables? How will their need for access affect your overall security plan?

What nonstandard NIS maps are being used at your site? Can you convert them to NIS+ tables or create nonstandard NIS+ tables to store their information? Be sure to check their access rights.

Does your site use locally built applications that depend on NIS? Do you have commands or applications that make direct NIS calls, such as embedded yp_match() function calls? (See NIS and NIS+ API Function Equivalents for more information.)

Do you have any duplicate user and host names in your namespace? (See Resolving User/Host Name Conflicts for more information.)

How will the network installation procedures be affected by the transition to NIS+? Analyze the changes required, if any. Gauging the impact of NIS+ on your site administrative practices can help uncover potential roadblocks.

Train Administrators

Another goal of the introduction and familiarization program discussed in Become Familiar With NIS+ is to give the administrators at your site an opportunity to become familiar with NIS+ concepts and procedures. Classroom instruction alone is insufficient. Administrators need a chance to work in a safe test environment. The training should consist of:

• A formal course in NIS+ concepts and administration

• Basic NIS+ troubleshooting information and practice

• Information about your site's implementation strategy and plans

Write a Communications Plan

Prepare a plan to communicate your intentions to users long before you actually begin converting clients to NIS+. Tell them about the implementation plan and give them a way to obtain more information. As mentioned in Suggested Transition Phases, a typical transition goal is to keep the impact of the transition on clients to a minimum, but users might become concerned about the upcoming change. Send out email notices, conduct informative seminars, and designate email aliases or individuals to whom users can send questions.

Identify Required Conversion Tools and Processes

Consider creating or obtaining transition tools to help with the implementation. If your site already uses automated tools to administer individual systems or network services, consider porting them to operate under the versions of Solaris software and NIS+ that you will be using for the transition (see Use a Single Release of Software). Here are some suggestions for scripts you might want to write:

• A script to convert users to NIS+—make additions to the nisclient shell script

• A check script to verify the correctness of a user's NIS+ environment

• Backup and recovery scripts

• crontab entries for routine NIS+ maintenance

• Procedures for notification of outages

Scripts such as these ensure that the transition is carried out uniformly across domains, speed the transition, and reduce complaints. You should also prepare a set of standard configuration files and options, such as nsswitch.conf, that all clients across the namespace can use.

Identify Administrative Groups Used for Transition

Be sure that the NIS+ groups created as part of your namespace design (see Establishing Password-aging Criteria, Principles, and Rules) correspond to the administrative resources you have identified for the transition. You could require a different set of NIS+ groups for the transition than for routine operation of an NIS+ namespace. Consider adding remote administrators to your groups in case you need their help in an emergency.

Make sure that group members have the proper credentials, that namespace objects grant the proper access rights to groups, and that the right group is identified as the group owner of the right namespace objects.

The following table provides a summary of commands that operate on NIS+ groups and group permissions.

Determine Who Will Own the Domains

To take complete advantage of the features inherent in a domain hierarchy, distribute the ownership of domains to the organizations they are dedicated to supporting. This will free the administrators of the root domain from performing rudimentary tasks at the local level. When you know who owns what, you can provide guidelines for creating administrative groups and setting their access rights to objects.

Consider how to coordinate the ownership of NIS+ domains with the ownership of DNS domains. Here are some guidelines:

• The administration of the DNS domain structure should remain the responsibility of the highest-level administrative group at the site.

• This same administrative group also owns the top-level NIS+ domain.

• Responsibility for the administration of lower-level DNS and NIS+ domains is delegated to individual sites by the top-level administrative group. If the NIS+ domains are created along the same principles as the DNS domains (for instance, organized geographically), this delegation will be simple to explain.

Determine Resource Availability

Determine what administrative resources are required for the implementation. These are above and beyond the resources required for normal operation of NIS+. If your transition involves a long period of NIS+ and NIS compatibility, additional resources may be required.

Consider not only the implementation of the namespace design, but also conversion for the numerous clients and dealing with special requests or problems. Keep in mind that NIS+ has a steep learning curve. Administrators may be less efficient for awhile at performing support functions with NIS+ than they were with NIS. Consider not only formal training, but extensive lab sessions with hands-on experience.

Finally, even after the transition is complete, administrators will require extra time to become familiar with the everyday work flow of supporting NIS+.

Consider hardware resources. NIS servers are often used to support other network services, such as routing, printing, and file management. Because of the potential load on an NIS+ server, you should use dedicated NIS+ servers. This load-balancing simplifies the transition because it simplifies troubleshooting and performance monitoring. Of course, you incur the cost of additional systems. The question of how many servers you will need and how they should be configured is addressed in Planning the NIS+ Namespace: Identifying the Goals of Your Administrative Model.

Remember, these servers are required in addition to the NIS servers. Although the NIS servers might be decommissioned or recycled after the transition is complete, the NIS+ servers will continue to be used.

Resolve Conflicts Between Login Names and Host Names

The NIS+ authentication scheme does not allow machines and users to use the same names within a domain; for example, joe@joe is not permitted. Since NIS+ does not distinguish between credentials for hosts and login names, you can only use one credential type per name. If you have duplicate names in your namespace and you must keep the duplicate host name for some other reason, make this change: retain the user login name and alias the duplicate host names. Create a new name for the host and use the old name as an alias for the new name. See Resolving User/Host Name Conflicts for examples of illegal name combinations.

You must resolve name conflicts before the implementation can begin, but you should also plan on permanently checking new machines and user names during routine NIS+ operation. The nisclient script does name comparisons when you use it to create a client credential.

Examine All Information Source Files

Check all /etc files and NIS maps for empty fields or corrupted data before configuring NIS+. The NIS+ table-populating scripts and commands might not succeed if the data source files contain empty fields or extraneous characters. Fill blank fields or fix the data before you start. It is better to delete questionable users or machines from the /etc files or NIS maps before running NIS+ scripts, then add them back later after NIS+ is installed, than to proceed with the scripts and possibly corrupt data.

Remove the “.” from Host Names

Because NIS+ uses dots (periods) to delimit between machine names and domains and between parent and sub-domains, you cannot have a machine (host) name containing a dot. Before converting to NIS+ you must eliminate any dots in your hostnames. You can convert hostname dots to hyphens (-). For example, you cannot have a machine named sales.alpha. You can convert that name to sales-alpha. (See the hosts man page for detailed information on allowable hostnames.)

Remove the “.” from NIS Map Names

As described in Planning the NIS+ Namespace: Identifying the Goals of Your Administrative Model, NIS+ automounter tables have replaced the “.” (dot) in the table name with an underscore. You also need to make this change to the names of NIS maps that you will use during the transition. If you do not, NIS+ will confuse the dot in the name with the periods that distinguish domain levels in object names.

Be sure to convert the dot to underscores for all NIS maps, not just those of the automounter. Be aware, however, that changing the names of nonstandard NIS maps from dots to underscores may cause applications that use those nonstandard maps to fail unless you also modify the applications to recognize NIS+ syntax.

Document Your Current NIS Namespace

Documenting your current configuration will give you a clear point of departure for the transition. Make a list of the following items:

• Name and location of all current NIS domains and networks

• Host name and location of all current NIS servers, both master and slave

• Configuration of all current NIS servers, including:

  • Host name

  • CPU type

  • Memory size

  • Disk space available

  • Name of administrators with root access

• Nonstandard NIS maps

Correlate the list of your NIS clients with their eventual NIS+ domains. They must be upgraded to the current Solaris operating environment.

Create a Conversion Plan for Your NIS Servers

Take stock of your NIS servers. Although you can recycle them after the transition is complete, keep in mind that you will go through a stage in which you will need servers for both services. Therefore, you cannot simply plan to satisfy all your NIS+ server needs with your existing NIS servers.

You might find it helpful to create a detailed conversion plan for NIS servers, identifying which NIS servers will be used for NIS+ and when they will be converted. Do not use the NIS servers as NIS+ servers during the first stages of NIS-to-NIS+ transition. As described in Implementing NIS+: An Introduction, the implementation is most stable when you check the operation of the entire namespace as a whole before you convert any clients to NIS+.

Assign NIS servers to NIS+ domains and identify each server's role (master or replica). When you have identified the servers you plan to convert to NIS+ service, upgrade them to NIS+ requirements (see Server Memory Requirements).

Implementing NIS+: An Introduction

After you have performed the tasks described in the previous sections, most of the hard work is done. Now all you have to do is set up the namespace you designed and add the clients to it. This chapter describes how to do that. Before performing these steps, verify that all pre-transition tasks have been completed and that users at your site are aware of your plans.

If you plan to run NIS+ domains alongside DNS domains, you must set up one NIS+ sub-domain with each DNS domain. After you have set up a complete NIS+ namespace along with the first DNS domain and have verified that everything is working right, then you can set up the other NIS+ namespaces in parallel.

Phase I-Set Up the NIS+ Namespace

Set up the namespace with full DES authentication, even if the domains will operate in NIS-compatibility mode. Use the NIS+ scripts described in Chapter 4, Configuring NIS+ With Scripts for more explanation of NIS+ structure and concepts. Then perform the following steps:

1. Set up the root domain.

   If you are going to run the root domain in NIS-compatibility mode, use nisserver. (If you choose not to use the setup scripts, use the -Y flag of rpc.nisd and nissetup.)

2. Populate the root domain tables.

   You can use nispopulate to transfer information from NIS maps or text files. Of course, you can also create entries one at a time with nistbladm or nisaddent.

3. Set up clients of the root domain.

   Set up a few clients in the root domain so that you can properly test its operation. Use full DES authentication. Some of these client machines will later be converted to root replica servers and some will serve as machines for the administrators who support the root domain. NIS+ servers should never be an individual's machine.

4. Create or convert site-specific NIS+ tables.

   If the new NIS+ root domain requires custom, site-specific NIS+ tables, create them, with nistbladm and transfer the NIS data into them with nisaddent.

5. Add administrators to root domain groups.

   Remember, the administrators must have LOCAL and DES credentials (use nisaddcred). Their machines should be root domain clients and their root identities should also be NIS+ clients with DES credentials.

6. Update the sendmailvars table, if necessary.

   If your email environment has changed as a result of the new domain structure, populate the root domain's sendmailvars table with the new entries.

7. Set up root domain replicas.

   First convert the clients into servers (use rpc.nisd with -Y for NIS compatibility and also use -B if you want DNS forwarding), then associate the servers with the root domain by running nisserver -R.

   For NIS compatibility, run rpc.nisd with the -Y and edit the /etc/init.d/rpc file to remove the comment symbol (#) from the EMULYP line. For DNS forwarding, use the -B option with rpc.nisd.

8. Test the root domain's operation.

   Develop a set of installation-specific test routines to verify a client's functioning after the switch to NIS+. This will speed the transition work and reduce complaints. You should operate this domain for about a week before you begin converting other users to NIS+.

9. Set up the remainder of the namespace.

   Do not convert any more clients to NIS+, but go ahead and set up all the other domains beneath the root domain. This includes setting up their master and replica servers. Test each new domain as thoroughly as you tested the root domain until you are sure your configurations and scripts work properly.

10. Test the operation of the namespace.

    Test all operational procedures for maintenance, backup, recovery, and other scenarios. Test the information-sharing process between all domains in the namespace. Do not proceed to Phase II until the entire NIS+ operational environment has been verified.

11. Customize the security configuration of the NIS+ domains.

    This may not be necessary if everything is working well; but if you want to protect some information from unauthorized access, you can change the default permissions of NIS+ tables so that even NIS clients are unable to access them. You can also rearrange the membership of NIS+ groups and the permissions of NIS+ structural objects to align with administrative responsibilities.

Phase II-Connect the NIS+ Namespace to Other Namespaces

1. [Optional] Connect the root domain to the DNS namespace.

   An NIS+ client can be connected to the Internet using the name service switch. machines, if they are also DNS clients, can have their name service switch configuration files set to search for information in DNS zone files—in addition to NIS+ tables or NIS maps.

   Configure each client's /etc/nsswitch.conf and /etc/resolv.conf files properly. The /etc/nsswitch.conf file is the client's name service switch configuration file. The /etc/resolv.conf lists the IP addresses of the client's DNS servers.

2. Test the joint operation of NIS+ with DNS.

   Verify that requests for information can pass between the namespaces without difficulty.

3. If operating NIS+ in parallel with NIS, test the transfer of information.

   Use the nispopulate script to transfer information from NIS to NIS+. To transfer data from NIS+ to NIS, run nisaddent -d and then ypmake. (See the man pages for more information.) Use scripts to automate this process. Establish policies for keeping tables synchronized, particularly the hosts and passwd tables. Test the tools used to maintain consistency between the NIS and NIS+ environments. Decide when to make the NIS+ tables the real source of information.

4. Test operation of NIS+ with both DNS and NIS.

   Test all three namespaces together to make sure the added links do not create problems.

Phase III-Make the NIS+ Namespace Fully Operational

1. Convert clients to NIS+.

   Convert clients one workgroup at a time, and convert all workgroups in a subnet before starting on those of another subnet. That way, when you convert all the clients in a subnet, you can eliminate the NIS service on that subnet. Run the verification script after converting each client to make sure that the conversion worked properly. That verification script should inform the user which support structure is in place, to help with problems and how to report them. The actual steps required depend on the site.

   Use the nisclient script to convert NIS clients to NIS+ clients. If you need to modify the clients' DNS configuration, you must write your own scripts to automate that process.

   You can also save time if your site has a shared, mounted central directory similar to /usr/local. You could put the script in the central directory and, on the day of conversion, send email to clients asking them to run the script as superuser.

2. Monitor the status of the transition as clients are being converted.

   Track progress against your plan and all serious complications not anticipated in the planning stages. Announce your status so that interested parties can track it.

3. Decommission NIS servers.

   As all the clients on a subnet are converted to NIS+, decommission the NIS servers. If a particular subnet has some clients that require NIS service, use the NIS-compatibility feature of the NIS+ servers but do not retain the NIS servers.

4. Evaluate NIS+ performance.

   After the implementation is complete, test to see that NIS+ is working correctly.

5. Optimize the NIS+ environment.

   Based on the results of your performance evaluation, modify the NIS+ environment as needed. These improvements can be as simple as adding selected replicas in domains with high loads or as involved as rearranging the storage of NIS+ information for a group of domains.

6. Clean up new domains.

   If you did not change old domain names during the transition for the sake of simplicity, upgrade them now to the new NIS+ naming scheme. For example, if you left some domains with geographic labels while you converted to an organizational hierarchy, you now change the geographic names to their organizational versions.

Phase IV-Upgrade NIS-Compatible Domains

1. Convert the last NIS clients to NIS+.

   As soon as you can, eliminate the need for NIS-compatible NIS+ domains. Upgrading the last NIS clients to NIS+ will allow you to take advantage of NIS+ security features. You will not be able to eliminate the need for NIS-compatible NIS+ domains if you are running non-Solaris machines on your network.

2. Adjust your security configuration.

   When you have no more NIS clients, you can restart the NIS+ servers in standard mode and run nischmod on the NIS+ tables to change permission levels, eliminating the security hole caused by NIS compatibility. If you did not create credentials for NIS+ principals before, you must do that now. Restrict the access of unauthenticated principals.

3. Establish miscellaneous evaluation and improvement programs.

   Evaluate operational procedures to determine which ones can be improved, particularly procedures used to recover from problems. Plan for new NIS+ releases and possible functional enhancements. Track the development of Solaris components that might require new NIS+ tables. Look for automated tools that enable you to perform NIS+ administration functions more efficiently. Finally, work with internal developers to help them take advantage of the NIS+ API.

   This completes your transition to NIS+.

Chapter 27 Transitioning From NIS+ to LDAP

This chapter describes how to make the transition from using the NIS+ naming service to the LDAP naming service.

Overview

The NIS+ server daemon, rpc.nisd, stores NIS+ data in proprietary-format files in the /var/nis/data directory. While it is entirely possible to 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. Since this makes it possible for NIS+ and LDAP clients to share the same naming service information, it is easier to transition from using NIS+ as the main naming service, to using LDAP for the same role. For more information on using LDAP as a naming service, see System Administration Guide: Naming and Directory Services (DNS, NIS, and LDAP).

By default, the rpc.nisd daemon continues to work as before, relying only on the/var/nis/data NIS+ database. If desired, the system administrator can choose to use an LDAP server as the authoritative data repository for any subset of the NIS+ database. In this case, the /var/nis/data files serve as a cache for the rpc.nisd daemon, reducing LDAP lookup traffic, and enabling the rpc.nisd to continue working if the LDAP server is temporarily unavailable. In addition to continuous synchronization between NIS+ and LDAP, you can also perform uploads of NIS+ data to LDAP, or downloads of LDAP data to NIS+.

Mapping of data to and from LDAP is controlled by a flexible configuration file syntax. (All standard NIS+ tables (except for client_info.org_dir and timezone.org_dir ) are covered by a template mapping file, /var/nis/NIS+LDAPmapping.template), which should require little or no change for most NIS+ installations. (See client_info and timezone Tables for information on client_info.org_dir and timezone.org_dir.) In addition to locations for NIS+ data in the LDAP Directory Information Tree (DIT), the mapping file also allows establishing time-to-live (TTL) for NIS+ data sourced from LDAP. While there often is a one-to-one mapping between NIS+ column values and LDAP attribute values, the mapping file can be used to maintain more complicated relationships as well.

The new /etc/default/rpc.nisd file is used to select LDAP server and authentication, and controls some general rpc.nisd behavior. See rpc.nisd(4). The details of the mapping is specified via the /var/nis/NIS+LDAPmapping file. For more information, see NIS+LDAPmapping(4). The name of this file can be changed using the -m command-line option of rpc.nisd. For more information, see rpc.nisd(1M).

The following terms are used in this chapter.

• Container

  A container is the location in the LDAP DIT where all related entries are stored. For example, user account information is often stored in the ou=People container, while host address information can be stored in the ou=Hosts container.

• Netname

  A netname is an entity in secure RPC (user or machine) that can be authenticated.

• Mapping

  Mapping is the relationship between an NIS+ object and an LDAP entry. For example, data from the name column in the passwd.org_dir NIS+ table (such as the user name of an account) corresponds to the LDAP uid attribute of the posixAccount object class in the ou=People container. The configuration can establish a mapping between the name column and the uid attribute. You can also say that the name column is mapped to the uid attribute (or vice versa).

• Principal

  A principal is an entity in NIS+ (user or machine) that can be authenticated. Usually, there is a one-to–one correspondence between netnames and principal names.

Configuration Files

Two configuration files control rpc.nisd operation.

• /etc/default/rpc.nisd

  This file contains information regarding the LDAP server and authentication, the NIS+ base domain, the LDAP default search base, exception processing, and general rpc.nisd configuration, which applies whether or not LDAP mapping is in effect.

• /var/nis/NIS+LDAPmapping

  This file contains information on mapping of NIS+ data to and from LDAP. The template file (/var/nis/NIS+LDAPmapping.template) covers all standard NIS+ objects, except client_info.org_dir and timezone.org_dir. See client_info and timezone Tables and NIS+LDAPmapping(4).

Configuration is done by assigning values to pre-defined attributes. In addition to the configuration files, the configuration attributes can also be read from LDAP (see Storing Configuration Information in LDAP) or can be specified on the rpc.nisd command line by way of the -x option. If the same attribute is specified in more than one place, the priority order is (from higher to lower) as follows.

1. rpc.nisd -x option

2. Configuration file

3. LDAP

Creating Attributes and Object Classes

Depending on how you configure the NIS+/LDAP mapping, you might need to create a number of new LDAP attributes and object classes. The examples show how to do this by specifying LDIF data that can be used as input to the ldapadd command. Create a file containing the LDIF data, and then invoke ldapadd(1).

# ldapadd -D bind-DN—f ldif -file

This method works with the iPlanet^TM Directory Server 5.1 , and might work with other LDAP servers as well.

Except for the defaultSearchBase, preferredServerList, and authenticationMethod attributes, as well as the SYNTAX specifications, the object identifiers (OIDs) used in this chapter are intended for illustration only. As no official OIDs have been assigned, you are free to use any suitable OIDs.

Getting Started

For an introduction to the configuration needed to start using an LDAP repository for NIS+ data, see NIS+LDAPmapping(4). The remainder of this section goes into more detail about the organization of the configuration files.

/etc/default/rpc.nisd

All assignments in the /etc/default/rpc.nisd file are of the attributeName=value type.

General Configuration

The following attributes control general configuration of the rpc.nisd, and are active whether or not LDAP mapping is in effect. They should generally be left at their default values. See rpc.nisd(4) for more information.

• nisplusNumberOfServiceThreads

• nisplusThreadCreationErrorAction

• nisplusThreadCreationErrorAttempts

• nisplusThreadCreationErrorTimeout

• nisplusDumpErrorAction

• nisplusDumpErrorAttempts

• nisplusDumpErrorTimeout

• nisplusResyncService

• nisplusUpdateBatching

• nisplusUpdateBatchingTimeout

Configuration Data From LDAP

The following attributes control the reading of other configuration attributes from LDAP. These attributes cannot themselves reside in LDAP. They are read only from the command line or the configuration file. See rpc.nisd(4) for more information.

• nisplusLDAPconfigDN

• nisplusLDAPconfigPreferredServerList

• nisplusLDAPconfigAuthenticationMethod

• nisplusLDAPconfigTLS

• nisplusLDAPconfigTLSCertificateDBPath

• nisplusLDAPconfigProxyUser

• nisplusLDAPconfigProxyPassword

Server Selection

• preferredServerList

  Specify the LDAP server and port number.

  # LDAP server can be found at port 389 # LDAP server can be found at port 389 on the local machine # preferredServerList=127.0.0.1 # Could also be written # preferredServerList=127.0.0.0.1:389 LDAP server on the machine at IP # address "1.2.3.4", at port 65042 # preferredServerList=1.2.3.4:65042

Authentication and Security

• authenticationMethod

• nisplusLDAPproxyUser

• nisplusLDAPproxyPassword

The authentication method and, if appropriate for the method selected, the proxy user (bind distinguished name [DN]) and password (key or other shared secret) to be used between the rpc.nisd daemon and the LDAP server. See Security and Authentication for more information.

• nisplusLDAPTLS

• nisplusLDAPTLSCertificateDBPath

Default Location in LDAP and NIS+

• defaultSearchBase

  The point in the LDAP DIT where the containers for RFC 2307- style naming services data live. This is the default used when individual container DNs do not specify a full search base. See nisplusLDAPobjectDN for more information.

• nisplusLDAPbaseDomain

  The default NIS+ domain name to use when NIS+ object specifications (see nisplusLDAPdatabaseIdMapping) are not fully qualified.

Timeout/Size Limits and Referral Action for LDAP Communication

• nisplusLDAPbindTimeout

• nisplusLDAPmodifyTimeout

• nisplusLDAPaddTimeout

• nisplusLDAPdeleteTimeout

The above parameters are timeouts for the ldap bind, modify, add, and delete operations, respectively. They should generally be left at their default values.

• nisplusLDAPsearchTimeout

• nisplusLDAPsearchTimeLimit

The above parameters set the timeout for the LDAP search operation, and request a server-side search time limit, respectively. Since the nisplusLDAPsearchTimeLimit will control how much time the LDAP server spends on the search request, make sure that nisplusLDAPsearchTimeLimit is not smaller than nisplusLDAPsearchTimeout. Depending on the performance of the NIS+ server, the LDAP server, and the connection between them, you might have to increase the search limits from the default values. Watch for timeout syslog messages from rpc.nisd as a clue to making these values larger.

• nisplusLDAPsearchSizeLimit

  The above parameter requests a limit on the amount of LDAP data returned for an LDAP search request. The default is to ask for no limitation. This is a server side limit. The LDAP server might impose restrictions on the maximum, and these restrictions might be tied to the proxy user (bind DN) used. Make sure that the LDAP server allows the rpc.nisd to transfer enough data to account for the largest container (depending on the site, often the container used for passwd.org_dir, mail_aliases.org_dir, or netgroup.org_dir). Consult your LDAP server documentation for more information.

• nisplusLDAPfollowReferral

  The above parameter defines the action to be taken when an LDAP operation results in a referral to another LDAP server. The default is to not follow referrals. Enable follow referrals if you want or need referrals to be honored. Keep in mind that while referrals are convenient, they can also slow down operations by making the rpc.nisd talk to multiple LDAP servers for each request. The rpc.nisd should generally be pointed directly to an LDAP server that can handle all LDAP requests that the rpc.nisd might make.

Error Actions

The following parameters define the actions to take when an error occurs during an LDAP operation. You should generally leave these at their defaults. See rpc.nisd(4) for more information.

• nisplusLDAPinitialUpdateAction

• nisplusLDAPinitialUpdateOnly

• nisplusLDAPretrieveErrorAction

• nisplusLDAPretrieveErrorAttempts

• nisplusLDAPretrieveErrorTimeout

• nisplusLDAPstoreErrorAction

• nisplusLDAPstoreErrorAttempts

• nisplusLDAPstoreErrorTimeout

• nisplusLDAPrefreshErrorAction

• nisplusLDAPrefreshErrorAttempts

• nisplusLDAPrefreshErrorTimeout

General LDAP Operation Control

• nisplusLDAPmatchFetchAction

  The above parameter determines whether or not LDAP data should be pre-fetched for NIS+ match operations. In most cases, leave this value at the default. See rpc.nisd(4) for more information.

/var/nis/NIS+LDAPmapping

The name of the above configuration can be changed via the -m option of rpc.nisd(1M). The presence of the NIS+LDAPmapping file serves as a master switch for NIS+/LDAP mapping.

If you use a name other than the default for the mapping file, you will have to edit the /etc/init.d/rpc boot script to specify the mapping file name on the rpc.nisd startup line.

For each NIS+ object that should be mapped to and/or from LDAP, the NIS+LDAPmapping file specifies two to five attributes, depending on the object and whether or not the default values are sufficient.

nisplusLDAPdatabaseIdMapping

You must establish an alias to be used in the other mapping attributes. If the NIS+ object name is not fully qualified (does not end in a dot), the value of the nisplusLDAPbaseDomain is appended.

For example,

nisplusLDAPdatabaseIdMapping	rpc:rpc.org_dir 

defines the database id rpc as an alias for the NIS+ rpc.org_dir table.

Note that NIS+ table objects might appear twice with two different database ids, once for the table object itself (if the object should be mapped to LDAP), and once for the table entries. For example,

nisplusLDAPdatabaseIdMapping	rpc_table:rpc.org_dir
nisplusLDAPdatabaseIdMapping	rpc:rpc.org_dir

defines the database ids rpc_table and rpc as aliases for the rpc.org_dir table. Later definitions will make it clear that rpc_table is used for the rpc.org_dir table object, and rpc for the entries in that table.

nisplusLDAPentryTtl

Since the rpc.nisd daemon's local database (in memory and on disk) functions as a cache for LDAP data, the nisplusLDAPentryTtl attribute allows you to set the time-to-live (TTL) values of entries in that cache. There are three TTLs for each database ID. The first two control the initial TTL when the rpc.nisd first loads the corresponding NIS+ object data from disk, and the third TTL is assigned to an object when it is read or refreshed from LDAP.

For example the following results in the rpc.org_dir table object getting an initial TTL randomly selected in the range 21600 to 43200 seconds.

nisplusLDAPentryTtl	rpc_table:21600:43200:43200

When that initial TTL expires and the table object is refreshed from LDAP, the TTL will be set to 43200 seconds.

Similarly the following will assign an initial TTL between 1800 and 3600 seconds to the entries in the rpc.org_dir table when it is first loaded.

nisplusLDAPentryTtl	rpc:1800:3600:3600

Each entry gets its own randomly selected TTL in the range specified. When a table entry expires and is refreshed, the TTL is set to 3600 seconds.

When selecting TTL values, consider the trade-off between performance and consistency. If the TTLs used for LDAP data cached by the rpc.nisd are very long, performance is the same as if rpc.nisd was not mapping data from LDAP at all. However, if the LDAP data is changed (by some entity other than rpc.nisd), it can also take a very long time before that change is visible in NIS+.

Conversely, selecting a very short (or even zero) TTL means that changes to LDAP data are quickly visible in NIS+, but can also impose a significant performance penalty. Typically, an NIS+ operation that also reads data from or writes data to LDAP will take at least two to three times longer (plus the LDAP lookup overhead) than the same operation without LDAP communication. Although performance can vary greatly depending on the hardware resources, scanning a large (tens of thousands or hundreds of thousands of entries) LDAP container to identify NIS+ entries that should be refreshed can take a long time. The rpc.nisd daemon performs this scan in the background, continuing to serve possibly stale data while it is running, but the background scan still consumes CPU and memory on the NIS+ server.

Carefully consider how critical it is to have NIS+ data in close synchronization with LDAP, and select the longest TTL that is acceptable for each NIS+ object. The default (when no nisplusLDAPentryTtl is specified) is 1 hour. The template mapping file /var/nis/NIS+LDAPmapping.template changes this to 12 hours for objects other than table entries. However, there is no auto-recognition of non-entry objects, so if you add mapping for a non-entry object, the TTL will default to 1 hour.

There are no TTLs for nonexistent objects. Hence, no matter which TTLs are in effect for LDAP-mapped entries in an NIS+ table, a request for an entry that does not exist in NIS+ will query LDAP for that entry.

nisplusLDAPobjectDN

For each mapped NIS+ object, nisplusLDAPobjectDN establishes the location in the LDAP DIT where the object data resides. It also allows specification of the action to take when an LDAP entry is deleted. Each nisplusLDAPobjectDN value has three parts. The first specifies where LDAP data is read from, the second to where it is written, and the third what should happen when LDAP data is deleted. Refer to the following example.

nisplusLDAPobjectDN	rpc_table:\ 
										cn=rpc,ou=nisPlus,?base?\
													objectClass=nisplusObjectContainer:\ 
										cn=rpc,ou=nisPlus,?base?\ 
													objectClass=nisplusObjectContainer,\ 
														objectClass=top

The above example shows that the rpc.org_dir table object should be read from the DN cn=rpc,ou=nisPlus, (since the value ends in a comma, the value of the defaultSearchBase attribute is appended), with scope base, and that entries with a value of nisplusObjectContainer for the ObjectClass attribute are selected.

The table object is written to the same place. The delete specification is missing, which implies the default action, which is as follows. If the NIS+ table object is deleted, the entire LDAP entry should also be deleted.

If data should be read from, but not written to LDAP, omit the write portion (and the colon separating it from the read part).

nisplusLDAPobjectDN	rpc_table:\
										cn=rpc,ou=nisPlus,?base?\
										objectClass=nisplusObjectContainer

Note that the nisplusObjectContainer object class is not part of RFC 2307. In order to use it, you must configure your LDAP server as detailed in Mapping NIS+ Objects Other Than Table Entries.

For the rpc.org_dir table entries, you could use the following example.

nisplusLDAPobjectDN rpc:ou=Rpc,?one?objectClass=oncRpc:\
											ou=Rpc,?one?objectClass=onRpc,objectClass=top

The above shows that the table entries are read from and written to the base ou=Rpc. Again, the trailing comma appends the defaultSearchBase value. Select entries that have an objectClass attribute value of oncRpc. When creating an entry in the ou=Rpc container in LDAP, you also must specify top as an objectClass value.

As an example showing a non-default delete specification, consider the following.

nisplusLDAPobjectDN	user_attr:\
										ou=People,?one?objectClass=SolarisUserAttr,\
											solarisAttrKeyValue=*:\
										ou=People,?one?objectClass=SolarisUserAttr:\
											dbid=user_attr_del

The user_attr.org_dir data resides in the ou=People LDAP container, which it shares with account information from other sources, such as the passwd.org_dir NIS+ table.

Select entries in that container that have the solarisAttrKeyValue attribute, since only those contain user_attr.org_dir data. The dbid=user_attr_del portion of the nisplusLDAPobjectDN shows that when an entry in the user_attr.org_dir NIS+ table entry is deleted, deletion of the corresponding LDAP entry (if any) should follow the rules in the rule set identified by the user_attr_del database ID. See nisplusLDAPcolumnFromAttribute for more information.

nisplusLDAPattributeFromColumn

nisplusLDAPattributeFromColumn specifies the rules used to map NIS+ data to LDAP. Mapping rules for the other direction is controlled by nisplusLDAPcolumnFromAttribute.

nisplusLDAPcolumnFromAttribute

nisplusLDAPcolumnFromAttribute specifies the rules used to map LDAP data to NIS+.

The full entry mapping syntax can be found on NIS+LDAPmapping(4). However, a few examples should make things clearer.

The NIS+ rpc.org_dir table contains four columns called cname, name, numbe, and comment. Therefore, the entries for the NIS+ RPC program number (100300) with the canonical name nisd and the aliases rpc.nisd and nisplusd could be represented by the following NIS+ entries in rpc.org_dir.

nisd nisd 100300	NIS+ server
nisd rpc.nisd 100300	NIS+ server
nisd nisplusd 100300	NIS+ server

Assuming the defaultSearchBase value is dc=some,dc=domain, the corresponding LDAP entry, as listed by ldapsearch(1), would be the following.

cn=nisd,ou=Ppc,dc=some,dc=domain
cn=nisd
cn=rpc.nsid
cn=nisplusd
oncrocnumber=100300
description=NIS+ server
objectclass=oncRpc
objectclass=top

This makes for a simple one-to-one mapping between NIS+ and LDAP data, and the corresponding mapping attribute value going from NIS+ to LDAP is the following.

nisplusLDAPattributeFromColumn \ 
rpc:		dn=("cn=%s,", name), \ 
				cn=cname, \
				cn=name, \
				oncRpcNumber=number, \
				description=comment

This constructs the DN for the entry to be cn=%s, with the value of the cname column substituted for %s.

cn=nisd,

Since the value ends in a comma, the read base value from the nisplusObjectDN is appended, and you have the following.

cn=nisd,ou=Rpc,dc=some,dc=domain

The oncRpcNumber and description attribute values are just simple assignments of the corresponding NIS+ column values. The rpc.nisd will collect the multiple NIS+ entries into one LDAP entry, with multiple cn values to represent the different name column values.

Similarly, the mapping from LDAP to NIS+ would be as follows.

nisplusLDAPcolumnFromAttribute \ 
 					rpc:		cname=cn, \
			 						(name)=(cn), \
									number=oncRpcNumber, \
									comment=description

The above assigns the oncRpcNumber and description values to the corresponding NIS+ columns. The multi-valued cn (denoted by (cn)) is mapped to multiple name column values (denoted by (name)). Since the name column cannot be multi-valued, the rpc.nisd creates one NIS+ entry for each cn value.

Finally, the nisplusLDAPattributeFromColumn value is an example of rule sets used for deletion.

nisplusLDAPattributeFromColumn \
user_attr_del:	dn=("uid=%s,", name), \
						SolarisUserQualifier=, \
						SolarisAttrReserved1=, \
 						SolarisAttrReserved2=, \
						SolarisAttrKeyValue= 

Again, the user_attr.org_dir data shares the ou=People container with other account information (from the passwd.org_dir and other tables). If an entry in the user_attr.org_dir table is deleted, you probably do not want to delete the entire ou=People entry. Instead, the delete entry above says that when a user_attr.org_dir entry is deleted, the SolarisUserQualifier, SolarisAttrReserved1, SolarisAttrReserved2, and SolarisAttrKeyValue attributes (if any) are deleted from the ou=People entry specified by the following rule.

dn=("uid=%s,", name)

The rest of the LDAP entry is left unchanged.

NIS+ to LDAP Migration Scenarios

Likely scenarios for a migration from NIS+ to LDAP include the following.

• Convert all NIS+ clients to LDAP in one operation. You can use the rpc.nisd daemon to upload any NIS+ data that does not yet exist in LDAP. See How to Convert All NIS+ Data to LDAP in One Operation.

• Do a gradual migration from NIS+ to LDAP. Start by converting NIS+ data to LDAP (see How to Convert All NIS+ Data to LDAP in One Operation). You could have both NIS+ and LDAP clients sharing the same naming service data, and let the rpc.nisd automatically keep NIS+ and LDAP data synchronized. Initially, perhaps, NIS+ would be authoritative, and the LDAP server(s) would maintain a duplicate of the NIS+ data for the benefit of LDAP clients. At a convenient time, LDAP can become the authoritative naming service, and NIS+ service gradually phased out, until there are no more NIS+ clients.

• LDAP is already used as a naming service, so you need to merge the NIS+ and LDAP data. There are three possible ways to perform this merge.

  • Add the NIS+ data to LDAP. Entries that exist in NIS+, but not in LDAP, are added to LDAP. Entries that appear both in NIS+ and LDAP, but with different data, end up with the NIS+ data. See How to Convert All NIS+ Data to LDAP in One Operation.

  • Overwrite the NIS+ data with the LDAP data. If there are entries that exist in NIS+ but not in LDAP, they will disappear from NIS+. Entries that exist both in NIS+ and LDAP end up with the LDAP data. See How to Convert All LDAP Data to NIS+ in One Operation.

  • Merge NIS+ and LDAP data, resolving conflicts on an individual basis. See Merging NIS+ and LDAP Data.

How to Convert All NIS+ Data to LDAP in One Operation

1. Use the rpc.nisd to upload any NIS+ data that does not yet exist in LDAP.

   Assuming all NIS+/LDAP data mappings have been established in the default location (/var/nis/NIS+LDAPmapping), use the following command.

   # /usr/sbin/rpc.nisd -D \

   —x nisplusLDAPinitialUpdateAction=to_ldap \

   -x nisplusLDAPinitialUpdateOnly=yes

   The above would make the rpc.nisd upload data to LDAP, and then exit. The NIS+ data would be unaffected by this operation.

   See the nisplusLDAPinitialUpdateAction attribute on rpc.nisd(4).

How to Convert All LDAP Data to NIS+ in One Operation

1. Use the rpc.nisd to download all LDAP data to NIS+, overwriting existing NIS+ data.

   Assuming all NIS+/LDAP data mappings have been established in the default location (/var/nis/NIS+LDAPmapping), use the following command.

   # /usr/sbin/rpc.nisd -D \

   -x nisplusLDAPinitialUpdateAction=from_ldap \

   -x nisplusLDAPinitialUpdateOnly=yes

   The above would make the rpc.nisd daemon download data from LDAP, and then exit. The LDAP data would be unaffected by this operation.

   See the nisplusLDAPinitialUpdateAction attribute on rpc.nisd(4).

Merging NIS+ and LDAP Data

NIS+ to LDAP Migration Scenarios showed how to synchronize NIS+ and LDAP data when data conflicts between the two should be resolved by letting either the NIS+ or the LDAP data be authoritative. Merging data requires a more complicated procedure.

The example procedure in this section assumes the following.

• You are putting a backup of the NIS+ data in the /nisbackup directory.

• Valid mapping configuration already exists in /etc/default/rpc.nisd and /var/nis/tmpmap (for tables that should be merged).

• Flat file representations of the NIS+ data before the merge are stored in /before, and after-merge representations in /after.

• niscat is used to dump flat file representations of custom NIS+ tables not supported by nisaddent(1M). You might have your own commands or scripts for dumping and loading such custom tables from and to NIS+. If so, those commands/scripts should be used in preference to niscat since the latter has no convenient counterpart to load data back into NIS+.

  If you are forced to dump data using niscat(1), you can use nistbladm(1) to load entries back into NIS+ one by one.

• Your command path includes /usr/lib/nis (which is where nisaddent(1M) resides).

How to merge NIS+ and LDAP data

If the LDAP data should change between the download in Step 4 and the upload in Step 10, the upload might overwrite those changes. For this reason, you should try to prevent modifications to the LDAP data during this procedure. Consult your LDAP server documentation for more information.

1. Back up all NIS+ data using the nisbackup command.

   # nisbackup -a /nisbackup

2. Identify the NIS+ tables that have data which must be merged with LDAP. Dump the contents of these tables to flat files. For example, dump the contents of group.org_dirusing nisaddent as follows.

   # nisaddent -d group | sort > /before/group

   Piping the nisaddent output to sort will make for convenient comparison later on.

3. Stop the rpc.nisd daemon.

   # pkill rpc.nisd

4. Download LDAP data to NIS+.

   # /usr/sbin/rpc.nisd -D -m tmpmap \

   -x nisplusLDAPinitialUpdateAction=from_ldap \

   -x nisplusLDAPinitialUpdateOnly=yes

5. Start the rpc.nisd daemon.

   # /usr/sbin/rpc.nisd

   The rpc.nisd daemon will now be serving the data downloaded from LDAP. If the conflicts to be resolved are such that NIS+ clients should not be exposed to them, make sure to perform this and the following steps when there are few (preferably no) active NIS+ clients.

6. Dump the NIS+ data for the affected tables.

   The following example uses the group.org_dir table.

   # nisaddent -d group | sort > /after/group

7. Use your favorite file merge procedure to produce merged versions of the tables. If no other tools are available, you can use diff(1) to collect differences between the /before and /after files, and merge manually with a text editor.

   The following example assumes that the merged results are available in /after.

8. Load the merged data into NIS+. The following example uses the group table.

   # nisaddent -m -f /after/group group

9. Remove LDAP entries that should not exist after the merge.

   A. If there are LDAP entries that do not exist in the (now merged) NIS+ data, and that should not exist in LDAP after the upload, you must remove those LDAP entries.

   Your LDAP server might provide a convenient method for removing multiple entries, such as a way to delete all entries in a container. If this is not the case, you can use ldapsearch(1) to generate a list of entries for each container. For example, to generate a list of all entries in the ou=Rpc container, use ldapsearch(1) as follows.

   # ldapsearch -h server-address -D bind-DN -w password \

   -b ou=Rpc,search-base 'objectClass=*' dn | \

   grep -i ou=Rpc | grep -v -i \^ou=Rpc > \

   /tmp/delete-dn

   See Performance and Indexing for an explanation of the meta-arguments (server-address, bind-DN, for example).

   B. You can now edit the result file (/tmp/delete-dn) to specify only those entries that should be removed. Alternatively, in order to remove all entries in the container, use the file as is, and rely on the NIS+ upload to restore the LDAP data. Either way, you should backup the LDAP data before performing the ldapdelete operation below.

   C. Use ldapdelete to remove LDAP entries, redirecting stdout (which usually is one blank line for each entry removed) to /dev/null.

   # ldapdelete —h server-address —D bind-DN —w password \

   /tmp/delete-dn /dev/null

   D. Repeat the above procedure for each container that has at least one entry which must be removed.

10. NIS+ now contains the merged data, which can be uploaded to LDAP. Do the following.

    Stop the rpc.nisd daemon.

    # pkill rpc.nisd

    Perform the upload.

    # /usr/sbin/rpc.nisd -D -m tmpmap \

    -x nisplusLDAPinitialUpdateAction=to_ldap \

    -x nisplusLDAPinitialUpdateOnly=yes

11. Restart the rpc.nisd daemon.

    • If the rpc.nisd daemon uses the LDAP repository, specify an appropriate mapping file.

    • If the rpc.nisd daemon provides NIS (YP) emulation, specify the -Y option.

    # /usr/sbin/rpc.nisd -m mappingfile [ -Y ]

    Alternatively, omit -x nisplusLDAPinitialUpdateOnly=yes from the upload command in Step 10. This will make the rpc.nisd daemon start serving NIS+ data when the upload is done.

Masters and Replicas

Only NIS+ masters are allowed to write data to LDAP. NIS+ replicas can obtain updates either from the NIS+ master (which might or might not have obtained it from LDAP), or they can read data directly from an LDAP server. A combination of the two is also possible. Therefore, there are two principal ways to arrange for NIS+ replication.

• Leave NIS+ replicas unchanged, and let them obtain their data updates from the NIS+ master.

  This arrangement has the advantage of configurational simplicity (only the NIS+ master need have a connection to an LDAP server), and also maintains the old replication relationship (master knows about new data first, replicas later). It is probably the most convenient solution while NIS+ remains authoritative for naming service data. However, it also lengthens the path between LDAP and NIS+ replica servers.

• Let NIS+ replicas obtain their data directly from LDAP instead of from the NIS+ master.

  In this case, replicas could have updated data before or after the NIS+ master, depending on lookup traffic and TTLs for data derived from LDAP. This arrangement is more complicated, but can be convenient when LDAP is the authoritative naming services repository, and few or no updates are made directly to NIS+ data.

Replication Timestamps

When an NIS+ replica is obtaining data for at least one object in a particular NIS+ directory from LDAP, the update timestamps printed by nisping(1M) do not necessarily indicate the degree of data consistency between the NIS+ master and the replica. For example, assume that the NIS+ directory dir1 contains the tables table1 and table2. When the replica is obtaining data for both table1 and table2 from the NIS+ master, you might see an output like the following.

# nisping dir1

Master server is "master.some.domain."
Last update occurred at Mon Aug  5 22:11:09 2002

Replica server is "replica.some.domain." 		
	Last Update seen was Mon Aug  5 22:11:09 2002

The above indicates that the master and replica have exactly the same data. However, if the replica is getting data for either or both of table1 and table2 from LDAP, the output only shows that the replica has received an NIS_PING from the master, and updated its resynchronization time stamp for housekeeping purposes. The data in the table or tables mapped from LDAP might differ from that on the NIS+ master if either of the following are true.

• The LDAP data differs from that on the NIS+ master.

• The replica has data in its cache (its local version of the NIS+ database) that has not expired, but that is not up to date with LDAP.

If you cannot accept this type of data inconsistency, let all NIS+ replicas obtain their data from the NIS+ master only. Once you have configured the NIS+ master to get data from LDAP, you do not need to make modifications to the replicas.

The Directory Server

The LDAP mapping portion of the rpc.nisd daemon uses LDAP protocol version 3 to talk to the LDAP server. The default mapping configuration (/var/nis/NIS+LDAPmapping.template) expects that the LDAP server supports an extended version of RFC 2307. RFCs can be retrieved from http://www.ietf.org/rfc.html. While the mapping between NIS+ and LDAP data can be modified using NIS+LDAPmapping(4), there is a basic assumption that the LDAP data is organized along the principles laid out in RFC 2307.

For example, in order to share account information between direct LDAP clients and NIS+ clients, the LDAP server must support storing account (user) passwords in the UNIX crypt format. If the LDAP server cannot be configured to do so, you can still store NIS+ data, including accounts, in LDAP. However, you will not be able to fully share account information between NIS+ users and LDAP bindDNs.

Configuring the iPlanet Directory Server 5.1

Refer to the iPlanet^TM Directory Server 5.1 Collection for detailed instructions on the installation, setup and administration of the iPlanet Directory Server 5.1.

You can use idsconfig(1M) to configure the iPlanet Directory Server version 5.1 for LDAP clients using LDAP as a naming service. The setup provided by idsconfig(1M) is also appropriate when using NIS+ with an LDAP data repository.

If you are using an LDAP server other than iPlanet Directory Server 5.1, you must manually configure the server to support the RFC 2307 schemas.

For more information on idsconfig, refer to System Administration Guide: Naming and Directory Services (DNS, NIS, and LDAP).

Assigning Server Address and Port Number

The /etc/default/rpc.nisd file is set up to use a local LDAP server at port 389. If this is not correct in your configuration, establish a new value for the preferredServerList attribute. For example, to use an LDAP server at IP address 192.0.0.1 and port 65535, you specify the following.

preferredServerList=192.0.0.1:65535

Security and Authentication

Authentication between NIS+ clients and the NIS+ server is not affected when the NIS+ server is obtaining data from LDAP. However, in order to maintain the integrity of the NIS+ data when it is stored in LDAP, consider configuring authentication between the rpc.nisd daemon and the LDAP server. Several different types of authentication are available, depending on the capabilities of the LDAP server.

The LDAP authentication supported by the rpc.nisd daemon includes the following.

• none

  The none authentication method is the default. While using none requires no setup, it also provides no security. It is only suitable for use in environments that have no security requirements at all.

  To use the none authentication, make sure that the authenticationMethod attribute has the following value.

  authenticationMethod=none

The authentication methods that actually provide at least some security typically require that you associate a shared secret (a password or key) with a DN in LDAP. The DN you select for use by the rpc.nisd daemon can be unique, or can also be used for other purposes. It should have appropriate capabilities to support the expected LDAP traffic. For example, if the rpc.nisd daemon should be able to write data to LDAP, the selected DN must have the right to add/update/delete LDAP data in the containers used for the NIS+ data. Also, the LDAP server might, by default, impose limitations on resource usage (such as search time limits or search result size limitations). If this is the case, the selected DN must have sufficient capabilities to support enumeration of the NIS+ data containers.

• simple

  The simple authentication method provides authentication by unencrypted exchange of a password string. Since the password is sent in the clear between the LDAP client (the rpc.nisd daemon) and LDAP server, the simple method is suitable only when information exchange between the NIS+ and LDAP servers is protected by some other method.

  For instance, transport layer encryption of LDAP traffic, or the special case where the NIS+ and LDAP server is one and the same system, and the NIS+/LDAP traffic stays in the kernel, protected from the eyes of unauthorized users.

  Modify the configuration of the rpc.nisd daemon with the DN and password to use for the simple authentication. For example, if the DN is cn=nisplusAdmin,ou=People,dc=some,dc=domain, and the password aword, establish the following.

  authenticationMethod=simple nisplusLDAPproxyUser=cn=nisplusAdmin,ou=People,dc=some,dc=domain nisplusLDAPproxyPassword=aword

  Be sure to protect the place where the password is stored from unauthorized access. Remember that if the password is specified on the rpc.nisd command line, it might be visible to any user on the system via commands such as ps(1).

• sasl/digest-md5

  The sasl/digest-md5 authentication method provides authentication using the digest/md5 algorithm.

  Consult your LDAP server documentation for information on how to set up an authorization identity for use with digest-md5, and modify the /etc/default/rpc.nisd file to specify this identity and its associated password.

  authenticationMethod=sasl/digest-md5 nisplusLDAPproxyUser=cn=nisplusAdmin,ou=People,dc=some,dc=domain nisplusLDAPproxyPassword=aword

  Be sure to protect the file where the password is stored from unauthorized access.

• sasl/cram-md5

  Authentication using the cram/md5 algorithm. Probably only supported by the obsolete SunDS LDAP server.

  Consult your LDAP server documentation for information on how to set up a bind DN for use with cram-md5, and modify the /etc/default/rpc.nisd file to specify this DN and its associated password.

  authenticationMethod=sasl/cram-md5 nisplusLDAPproxyUser=cn=nisplusAdmin,ou=People,dc=some,dc=domain nisplusLDAPproxyPassword=aword

  Be sure to protect the file where the password is stored from unauthorized access.

Using SSL

The rpc.nisd daemon also supports transport layer encryption of LDAP traffic using SSL. Consult your LDAP server documentation to generate an SSL certificate for LDAP server authentication. Store the certificate in a file on the NIS+ server (/var/nis/cert7.db, for example) and modify /etc/default/rpc.nisd as follows.

nisplusLDAPTLS=ssl 
nisplusLDAPTLSCertificateDBPath=/var/nis/cert7.db 

Be sure to protect the certificate file from unauthorized access. Note that the above provides session encryption and authentication of the LDAP server to the rpc.nisd. It does not provide authentication of the rpc.nisd to the LDAP server, since the certificate does not contain anything that identifies the LDAP client (rpc.nisd). However, you can combine SSL with another authentication method (simple, sasl/digest-md5) in order to achieve mutual authentication.

For more information regarding LDAP security issues, refer to System Administration Guide: Naming and Directory Services (DNS, NIS, and LDAP).

Performance and Indexing

When the rpc.nisd daemon is asked to enumerate an NIS+ table (using niscat(1) for example) that is mapped from LDAP, it will enumerate the corresponding LDAP container if at least one entry in the table has an expired TTL. Although this container enumeration is done in the background, so that LDAP performance is of limited importance, it can nevertheless be beneficial to establish LDAP indices to speed up container enumeration for large containers.

To obtain an estimate of the amount of time required for enumeration of a particular container, you can use a command like the following.

% /bin/time ldapsearch -h server-address -D bind-DN -w password \

-b container, search-base 'cn=*' /dev/null

where

• server-address

  IP address portion of preferredServerList value from /etc/default/rpc.nisd

• bind-DN

  nisplusLDAPproxyUser value from /etc/default/rpc.nisd

• password

  nisplusLDAPproxyPassword value from /etc/default/rpc.nisd

• container

  One of the RFC 2307 container names (ou=Services, ou=Rpc, and so on.)

• search-base

  defaultSearchBase value from /etc/default/rpc.nisd

The "real" value printed by /bin/time is the elapsed (wall-clock) time. If this value exceeds a significant fraction (25 percent or more) of the TTL for the corresponding table entries (see Authentication and Security), it might be beneficial to index the LDAP container.

The rpc.nisd supports the simple page and VLV indexing methods. Refer to your LDAP server documentation to find out which indexing methods it supports, and how to create such indices.

Mapping NIS+ Objects Other Than Table Entries

You can store NIS+ objects other than table entries in LDAP. However, doing so has no particular value unless you also have NIS+ replicas that obtain those NIS+ objects from LDAP. The recommended choices are the following.

• There are no replicas, or the replicas obtain their data from the NIS+ master only.

  Edit the mapping configuration file (see NIS+LDAPmapping(4)) to remove the following attribute values for all non-table-entry objects.

  nisplusLDAPdatabaseIdMapping nisplusLDAPentryTtl nisplusLDAPobjectDN

  For example, if you started out from the /var/nis/NIS+LDAPmapping.template file, the sections you need to remove (or disable by commenting) are as follows.

  # Standard NIS+ directories nisplusLDAPdatabaseIdMapping basedir: . . .

  nisplusLDAPdatabaseIdMapping user_attr_table:user_attr.org_dir

  nisplusLDAPdatabaseIdMapping audit_user_table:audit_user.org_dir # Standard NIS+ directories nisplusLDAPentryTtl basedir:21600:43200:43200 . . .

  nisplusLDAPentryTtl user_attr_table:21600:43200:43200 nisplusLDAPentryTtl audit_user_table:21600:43200:43200 # Standard NIS+ directories nisplusLDAPobjectDN basedir:cn=basedir,ou=nisPlus,?base?\

  objectClass=nisplusObjectContainer:\ cn=basedir,ou=nisPlus,?base?\ objectClass=nisplusObjectContainer,\ objectClass=top . . .

  nisplusLDAPobjectDN audit_user_table:cn=audit_user,ou=nisPlus,?base?\ objectClass=nisplusObjectContainer:\ cn=audit_user,ou=nisPlus,?base?\ objectClass=nisplusObjectContainer,\ objectClass=top

• NIS+ replicas obtain their data from LDAP server.

  Create the nisplusObject attribute and nisplusObjectContainer object class as shown in the following example (LDIF data is suitable for ldapadd(1). Attribute and object class OIDs are for illustration only.)

  dn: cn=schema changetype: modify add: attributetypes attributetypes: ( 1.3.6.1.4.1.42.2.27.5.42.42.1.0 NAME 'nisplusObject' \ DESC 'An opaque representation of an NIS+ object' \ SYNTAX 1.3.6.1.4.1.1466.115.121.1.5 SINGLE-VALUE )

  dn: cn=schema changetype: modify add: objectclasses

  objectclasses(1.3.6.1.4.1.42.2.27.5.42.42.2.0 NAME'nisplusObjectContainer'\

  SUP top STRUCTURAL DESC 'Abstraction of an NIS+ object MUST ( cn $ nisplusObject ) )

  You also need to create a container for the NIS+ objects. The following LDIF syntax shows how to create the ou=nisPlus,dc=some,dc=domain container, and can be used as input to ldapadd(1).

  dn: ou=nisPlus,dc=some,dc=domain ou: nisPlus objectClass: top objectClass: organizationalUnit

NIS+ Entry Owner, Group, Access, and TTL

When NIS+ table entries are created from LDAP data, the default behavior is to initialize the entry object owner, group, access rights, and TTL using the corresponding values from the table object in which the entry object lives. This is normally sufficient, but there might be cases where these NIS+ entry attributes must be established individually. An example of this would be a site that did not use the rpc.nispasswdd(1M) daemon. In order to allow individual users to change their NIS+ passwords (and re-encrypt their Diffie-Hellman keys stored in the cred.org_dir table), passwd.org_dir and cred.org_dir entries for the user should be owned by the user, and have modify rights for the entry owner.

If you need to store table entry owner, group, access, or TTL in LDAP for one or more NIS+ tables, you need to do the following.

How to Store Additional Entry Attributes in LDAP

1. Consult your LDAP server documentation, and create the following new attributes and object class. (LDIF data is suitable for ldapadd. Attribute and object class OIDs are for illustration only.)

   dn: cn=schema changetype: modify add: attributetypes attributetypes: ( 1.3.6.1.4.1.42.2.27.5.42.42.4.0 NAME 'nisplusEntryOwner' \ DESC 'Opaque representation of NIS+ entry owner' \ SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE ) attributetypes: ( 1.3.6.1.4.1.42.2.27.5.42.42.4.1 NAME 'nisplusEntryGroup' \ DESC 'Opaque representation of NIS+ entry group' \ SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE ) attributetypes: ( 1.3.6.1.4.1.42.2.27.5.42.42.4.2 NAME 'nisplusEntryAccess' \ DESC 'Opaque representation of NIS+ entry access' \ SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE ) attributetypes: ( 1.3.6.1.4.1.42.2.27.5.42.42.4.3 NAME 'nisplusEntryTtl' \ DESC 'Opaque representation of NIS+ entry TTL' \ SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )

   dn: cn=schema changetype: modify add: objectclasses

   objectclasses:(1.3.6.1.4.1.42.2.27.5.42.42.5.0 NAME 'nisplusEntryData'\ SUP top STRUCTURAL DESC 'NIS+ entry object non-column data'\

   MUST ( cn ) MAY ( nisplusEntryOwner $ nisplusEntryGroup $\ nisplusEntryAccess $ nisplusEntryTtl ) )

2. Modify the nisplusLDAPobjectDN attribute value for the relevant table(s) so that the write portion includes the newly created nisplusEntryData object class.

   For example, for the passwd.org_dir table, assuming that you are using a mapping file based on /var/nis/NIS+LDAPmapping.template, edit as follows.

   nisplusLDAPobjectDN passwd:ou=People,?one?objectClass=shadowAccount,\ objectClass=posixAccount:\ ou=People,?one?objectClass=shadowAccount,\ objectClass=posixAccount,\ objectClass=account,objectClass=top

   Edit the attribute value as follows.

   nisplusLDAPobjectDN passwd:ou=People,?one?objectClass=shadowAccount,\ objectClass=posixAccount:\ ou=People,?one?objectClass=shadowAccount,\ objectClass=posixAccount,\ objectClass=nisplusEntryData,\ objectClass=account,objectClass=top

3. Edit the nisplusLDAPattributeFromColumn and nisplusLDAPcolumnFromAttribute attribute values to specify any desired subset of owner, group, access, or TTL.

   In Step 2, you created the LDAP attributes used to store these values. For NIS+, there are predefined pseudo-column names called zo_owner, zo_group, zo_access, and zo_ttl, respectively. For example, in order to store owner, group, and access for passwd.org_dir entries in LDAP, modify the nisplusLDAPattributeFromColumn value from the following.

   nisplusLDAPattributeFromColumn \ passwd: dn=("uid=%s,", name), \ cn=name, \ uid=name, \ userPassword=("{crypt$}%s", passwd), \ uidNumber=uid, \ gidNumber=gid, \ gecos=gcos, \ homeDirectory=home, \ loginShell=shell, \ (shadowLastChange,shadowMin,shadowMax, \ shadowWarning, shadowInactive,shadowExpire)=\ (shadow, ":")

   Edit to read as follows.

   nisplusLDAPattributeFromColumn \ passwd: dn=("uid=%s,", name), \ cn=name, \ uid=name, \ userPassword=("{crypt$}%s", passwd), \ uidNumber=uid, \ gidNumber=gid, \ gecos=gcos, \ homeDirectory=home, \ loginShell=shell, \ (shadowLastChange,shadowMin,shadowMax, \ shadowWarning, shadowInactive,shadowExpire)=\ (shadow, ":"), \ nisplusEntryOwner=zo_owner, \ nisplusEntryGroup=zo_group, \ nisplusEntryAccess=zo_access

   Similarly, to set NIS+ entry owner, group, and access from LDAP data for the passwd.org_dir table, modify the following.

   nisplusLDAPcolumnFromAttribute \ passwd: name=uid, \ ("{crypt$}%s", passwd)=userPassword, \ uid=uidNumber, \ gid=gidNumber, \ gcos=gecos, \ home=homeDirectory, \ shell=loginShell, \ shadow=("%s:%s:%s:%s:%s:%s", \ shadowLastChange, \ shadowMin, \ shadowMax, \ shadowWarning, \ shadowInactive, \ shadowExpire)

   Edit to read as follows.

   nisplusLDAPcolumnFromAttribute \ passwd: name=uid, \ ("crypt$%s", passwd)=authPassword, \ uid=uidNumber, \ gid=gidNumber, \ gcos=gecos, \ home=homeDirectory, \ shell=loginShell, \ shadow=("%s:%s:%s:%s:%s:%s", \ shadowLastChange, \ shadowMin, \ shadowMax, \ shadowWarning, \ shadowInactive, \ shadowExpire), \ zo_owner=nisplusEntryOwner, \ zo_group=nisplusEntryGroup, \ zo_access=nisplusEntryAccess

4. Restart the rpc.nisd daemon in order to make the mapping change take effect.

   First, however, you probably want to upload owner, group, access, and/or TTL entry data to LDAP. Perform an upload as shown in How to Convert All NIS+ Data to LDAP in One Operation.

Principal Names and Netnames

NIS+ authentication relies on principal names (a user or host name, qualified by the domain name) and netnames (the secure RPC equivalent of principal names) to uniquely identify an entity (principal) that can be authenticated. While RFC 2307 provides for storing the Diffie-Hellman keys used for NIS+ authentication, there is no specified place for the principal names or netnames.

The /var/nis/NIS+LDAPmapping.template file works around this problem by deriving the domain portion of principal and netnames from the owner name (itself a principal name) of the cred.org_dir table. Hence, if the NIS+ domain is x.y.z., and the owner of the cred.org_dir table is aaa.x.y.z., all principal names for NIS+ entries created from LDAP data will be of the following form.

user or system.x.y.z.

Netnames are of the following form.

unix.uid@x.y.z.

unix.nodename@x.y.z.

While this method of constructing principal and netnames probably is sufficient for most NIS+ installations, there are also some cases in which it fails, as shown in the following.

• The owner name of the cred.org_dir table belongs to a different domain than the one shared by the principal and netnames in the cred.org_dir table. This could be the case for a cred.org_dir table in a subdomain, if the owner is a principal from the parent domain. You can fix this problem in one of the following ways.

  • Change the owner of the cred.org_dir table to match the domain of the entries in the table.

  • Change the mapping rules for the cred.org_dir database IDs to use the owner of some other NIS+ object (which could be created especially for that purpose, if no suitable object already exists).

    For example, if the cred.org_dir table in the domain sub.dom.ain. is owned by master.dom.ain., but principal and netnames in cred.org_dir.sub.dom.ain. should belong to sub.dom.ain, you could create a link object as follows.

    # nisln cred.org_dir.sub.dom.ain. \

    credname.sub.dom.ain.

    Set the owner of the link object to an appropriate principal in the sub.dom.ain. as follows.

    # nischown trusted.sub.dom.ain. credname.sub.dom.ain.

    Edit the mapping file. Change

    (nis+:zo_owner[]cred.org_dir, "*.%s")), \

    to

    (nis+:zo_owner[]credname.sub.dom.ain., "*.%s")), \

    Note that the use of a link object called credname is an example. Any valid object type (except an entry object) and object name will do. The important point is to set the owner of the object to have the correct domain name.

  • If you do not want to give ownership even of a special purpose object to a principal from the domain used for the principal and netnames, create nisplusPrincipalName and nisplusNetname attributes as detailed below.

• The cred.org_dir table contains principal and netnames belonging to more than one domain.

  Consult the documentation for your LDAP server, and create the nisplusPrincipalName and nisplusNetname attributes, as well as the nisplusAuthName object class. (The following is LDIF data for ldapadd. Attribute and object class OIDs are for illustration only.)

  dn: cn=schema changetype: modify add: attributetypes attributetypes: ( 1.3.6.1.4.1.42.2.27.5.42.42.7.0 NAME 'nisplusPrincipalName' \ DESC 'NIS+ principal name' \ SINGLE-VALUE \ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )

  attributetypes: ( 1.3.6.1.4.1.42.2.27.5.42.42.9.0 NAME 'nisplusNetname' \ DESC 'Secure RPC netname' \ SINGLE-VALUE \ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) dn: cn=schema changetype: modify add: objectclasses objectclasses: ( 1.3.6.1.4.1.42.2.27.5.42.42.10.0 NAME 'nisplusAuthName' \ SUP top AUXILLIARY DESC 'NIS+ authentication identifiers' \ MAY ( nisplusPrincipalName $ nisplusNetname ) )

  You now need to enable the cred.org_dir mapping to use the newly created nisplusNetname and nisplusPrincipalName attributes. The template mapping file, /var/nis/NIS+LDAPmapping.template, contains commented-out lines for this purpose. See the nisplusObjectDN and nisplusLDAPattributeFromColumn/ nisplusLDAPcolumnFromAttribute attribute values for the credlocal, creduser, and crednode database IDs. Once you have edited your mapping file to this effect, restart the rpc.nisd daemon. Do not forget to add the -m option if your mapping file is not the default, and the -Y option if the rpc.nisd daemon should provide NIS (YP) emulation.

  # pkill rpc.nisd

  # /usr/sbin/rpc.nisd -m mapping-file [-Y]

client_info and timezone Tables

Because RFC 2307 does not provide schemas for the information kept in the NIS+ client_info.org_dir and timezone.org_dir tables, mapping of these tables is not enabled by default in the template mapping file (/var/nis/NIS+LDAPmapping.template). If you want to keep the client_info andtimezone information in LDAP, consult your LDAP server documentation, and create the new attributes and object classes discussed in the following sections.

client_info Attributes and Object Class

Create attributes and object class as below, and then create the container for the client_info data. The suggested container name is ou=ClientInfo. LDIF data is for ldapadd(1). The attribute and object class OIDs used in the following are examples only.

dn: cn=schema
changetype: modify
add: attributetypes
attributetypes:	( 1.3.6.1.4.1.42.2.27.5.42.42.12.0 \
		  NAME 'nisplusClientInfoAttr' \
		  DESC 'NIS+ client_info table client column' \
		  SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE )
attributetypes:	( 1.3.6.1.4.1.42.2.27.5.42.42.12.1 \
		  NAME 'nisplusClientInfoInfo' \
		  DESC 'NIS+ client_info table info column' \
		  SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )
attributetypes:	( 1.3.6.1.4.1.42.2.27.5.42.42.12.2 \
		  NAME 'nisplusClientInfoFlags' \
		  DESC 'NIS+ client_info table flags column' \
		  SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )

dn: cn=schema
changetype: modify
add: objectclasses
objectclasses:	( 1.3.6.1.4.1.42.2.27.5.42.42.13.0 \
		  NAME 'nisplusClientInfoData' \
		  DESC 'NIS+ client_info table data' \
		  SUP top STRUCTURAL MUST ( cn ) \
		  MAY ( nisplusClientInfoAttr $ nisplusClientInfoInfo $ nisplusClientInfoFlags ) )

To create the container, put the following LDIF data in a file. Substitute your actual search base for searchBase. )

dn: ou=ClientInfo, searchBase

objectClass: organizationalUnit

ou: ClientInfo

objectClass: top

Use the above file as input to the ldapadd command in order to create the ou=ClientInfo container. For example, if your LDAP administrator DN is cn=directory manager, and the file with the LDIF data is called cifile, do the following.

# ldapadd -D cn="directory manager" -f cifile

Depending on the authentication required, the ldapadd command might prompt for a password.

The /var/nis/NIS+LDAPmapping.template file contains commented-out definitions for the client_info.org_dir table. Copy these to the actual mapping file, enable by removing the comment character '#', and restart the rpc.nisd daemon. If necessary, synchronize NIS+ and LDAP data as described in NIS+ to LDAP Migration Scenarios.

timezone Attributes and Object Class

Create attributes and object class as below, and then create the container for the timezone data. The suggested container name is ou=Timezone. (The LDIF data is suitable for ldapadd(1). Attribute and object class OIDs are examples only.)

dn: cn=schema
changetype: modify
add: attributetypes
attributetypes:	( 1.3.6.1.4.1.42.2.27.5.42.42.15.0 NAME 'nisplusTimeZone' \
		  DESC 'tzone column from NIS+ timezone table' \
		  SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )

dn: cn=schema
changetype: modify
add: objectclasses
objectclasses:	( 1.3.6.1.4.1.42.2.27.5.42.42.16.0 NAME 'nisplusTimeZoneData' \
		  DESC 'NIS+ timezone table data' \
		  SUP top STRUCTURAL MUST ( cn ) \
		  MAY ( nisplusTimeZone $ description ) )

To create the ou=Timezone container, put the following LDIF data in a file. (Substitute your actual search base for searchBase.)

dn: ou=Timezone,searchBase ou: Timezone objectClass: top

objectClass: organizationalUnit

Use the above file as input to ldapadd(1) in order to create the ou=Timezone container. For example, if your LDAP administrator DN is cn=directory manager, and the file with the LDIF data is called tzfile.

# ldapadd -D cn="directory manager" -f tzfile

Depending on the authentication required, the ldapadd command might prompt for a password.

The /var/nis/NIS+LDAPmapping.template file contains commented-out definitions for the timezone.org_dir table. Copy these to the actual mapping file, enable by removing the comment character '#', and restart therpc.nisd daemon. If necessary, synchronize NIS+ and LDAP data as described in NIS+ to LDAP Migration Scenarios.

Adding New Object Mappings

The template mapping file, /var/nis/NIS+LDAPmapping.template, contains mapping information for all standard NIS+ objects. In order to support mapping of site or application specific objects, you will need to add new mapping entries. This is a simple task for non-entry (that is, directory, group, link, or table) objects, but can become complex for entry objects, if the LDAP organization of the corresponding entry data differs greatly from that used by NIS+. The following example shows the simple case.

How to Map Non-Entry Objects

1. Find the fully qualified name of the object to be mapped.

   If this name resides under the domain name specified by the nisplusLDAPbaseDomain attribute, you can omit the portion that equals the nisplusLDAPbaseDomain value.

   For example, if nisplusLDAPbaseDomain has the value some.domain., and the object to be mapped is a table called nodeinfo.some.domain., the object name can be shortened to nodeinfo.

2. Invent a database id to identify the object.

   The database id must be unique for the mapping configuration used, but is not otherwise interpreted. It does not show up in the LDAP data. In order to reduce confusion with entry object mappings, create a database id identifying the table object proper (not the table entries) using an explanatory string like _table at the end.

   For this example, use the database id nodeinfo_table, and establish the connection between the database id and the object in the standard mapping file location (/var/nis/NIS+LDAPmapping) by adding the following.

   nisplusLDAPdatabaseIdMapping nodeinfo_table:nodeinfo.some.domain.

   Assuming that nisplusLDAPbaseDomain is some.domain., the following would also work.

   nisplusLDAPdatabaseIdMapping nodeinfo_table:nodeinfo

3. Decide on a TTL for the object.

   This is the time during which the rpc.nisd daemon regards its local copy of the object as valid. When the TTL expires, the next reference to the object will initiate an LDAP lookup to refresh the object.

   There are two different TTL values. The first is set when the rpc.nisd daemon first loads the object from disk (after a reboot or restart), and the second pertains to all refreshes from LDAP. The first TTL is selected randomly from a configured range. For example, if nodeinfo_table should be valid for a period of between one and three hours following initial load, and for twelve hours thereafter, specify the following.

   nisplusLDAPentryTtl nodeinfo_table:3600:10800:43200

4. Decide where the object data should be stored in LDAP.

   The template mapping file suggests putting non-entry object data in the ou=nisPlus container.

   If you use this scheme, and have not yet created the appropriate attribute, object class, and container, see Mapping NIS+ Objects Other Than Table Entries.

   For example, assume you want to store the nodeinfo object in the ou=nisPlus,dc=some,dc=domain container, and that the LDAP entry should have the cn nodeinfo. Create the following nisplusLDAPobjectDN.

   nisplusLDAPobjectDN nodeinfo_table:\ cn=nodeinfo,ou=nisPlus,dc=some,dc=domain?base?\ objectClass=nisplusObjectContainer:\ cn=nodeinfo,ou=nisPlus,dc=some,dc=domain?base?\ objectClass=nisplusObjectContainer,\ objectClass=top

   Since NIS+ replicas do not write data to LDAP, you can use the nisplusLDAPobjectDN above for both master and replicas.

5. (Skip this step if the NIS+ object to be mapped has not yet been created in NIS+.) Store the object data in LDAP. You could use the rpc.nisd daemon for this purpose, but it is easier to use the nisldapmaptest(1M) utility, as you can leave the rpc.nisd daemon running.

   # nisldapmaptest -m /var/nis/NIS+LDAPmapping -o -t nodeinfo -r

   The —o option specifies the table object itself, not the table entries.

6. Verify that the object data is stored in LDAP. (This example assumes the LDAP server is running on the local machine at port 389.)

   # ldapsearch -b ou=nisPlus,dc=some,dc=domain cn=nodeinfo

   The output would appear similar to the following.

   cn=nodeinfo,ou=nisPlus,dc=some,dc=domain nisplusobject=NOT ASCII objectclass=nisplusObjectContainer objectclass=top cn=nodeinfo

7. Restart the rpc.nisd daemon so that it will start using the new mapping information. Do not forget the -m option if the mapping file has a name other than the default one. Append the -Y option if the rpc.nisd daemon is providing NIS (YP) service.

   # pkill rpc.nisd

   # /usr/sbin/rpc.nisd -m mappingfile [-Y]

Adding Entry Objects

NIS+LDAPmapping(4) specifies the syntax and semantics of table entry mapping in detail, and also provides examples that show how to use each syntactic element. However, the simplest and least error-prone approach is usually to identify an already existing mapping that is similar to what you want to do, and then copy and modify that existing mapping.

For example, assume that you have an NIS+ table called nodeinfo, which is used to store inventory and owner information for nodes. Assume that the NIS+ table was created by the following command.

# nistbladm -c -D access=og=rmcd,nw=r -s : nodeinfo_tbl \

cname=S inventory=S owner= nodeinfo.`domainname`.

The cname column is expected to contain the canonical name of the node. In other words, the same value as that of the cname column in the hosts.org_dir table for the node.

Also assume that the corresponding information is kept in the ou=Hosts container in LDAP, and that the nodeInfo object class (which is an invention for this example, and is not defined in any RFC) has cn as a MUST attribute, and that nodeInventory and nodeOwner are MAY attributes.

In order to upload existing nodeinfo data to LDAP, it will be convenient to create the new mapping attributes in a separate file. You could, for example, use /var/nis/tmpmapping.

1. Create a database id that identifies the NIS+ table to be mapped.

   nisplusLDAPdatabaseIdMapping nodeinfo:nodeinfo

2. Set the TTL for entries in the nodeinfo table. Since the information is expected to change only rarely, use a twelve hour TTL. When the rpc.nisd daemon first loads the nodeinfo table from disk, the TTLs for entries in the table are randomly selected to be between six and twelve hours.

   nisplusLDAPentryTtl nodeinfo:21600:43200:43200

3. Identify an existing mapping that has similar properties to the one you want to create. In this example, mapping the attribute values is trivial (straight assignment). Instead, the complication is that you store the LDAP data in an existing container, so that you have to be careful during removal of the nodeinfo data. You do not want to remove the entire ou=Hosts entry, just the nodeInventory and nodeOwner attributes. You will need a special deletion rule set for this purpose.

   To summarize, you are looking for a mapping that shares a container, and has a delete rule set. One possible candidate is the netmasks mapping, which shares the ou=Networks container, and does have a delete rule set.

4. The template netmasks mapping has the default mapping (from /var/nis/NIS+LDAPmapping.template) as follows.

   nisplusLDAPobjectDN netmasks:ou=Networks,?one?objectClass=ipNetwork,\ ipNetMaskNumber=*:\ ou=Networks,?one?objectClass=ipNetwork: dbid=netmasks_del

   Transferred to the new mapping for nodeinfo, the database id should be nodeinfo, the container ou=Hosts, and the object class nodeInfo. Thus, the first line of the nodeinfo mapping becomes the following.

   nisplusLDAPobjectDN nodeinfo:ou=Hosts,?one?objectClass=nodeInfo,\

   The second line in the netmasks mapping is the part of the search filter that selects only those ou=Networks entries that contain the ipNetMaskNumber attribute. In this example, select the ou=Hosts entries that have the following nodeInventory attribute.

   nodeInventory=*:\

   The third and fourth lines are the write portion of the nisplusLDAPobjectDN, and they specify where in LDAP nodeinfo data is written, as well as the rule set that is used when nodeinfo data is deleted. In this case, create a delete rule set identified by the database id nodeinfo_del. Because you are always writing to an existing entry in ou=Hosts, you only need to specify the object class for the nodeinfo data proper as follows.

   ou=Hosts,?one?objectClass=nodeInfo:\ dbid=nodeinfo_del

   Putting it all together, our nisplusLDAPobjectDN is the following.

   nisplusLDAPobjectDN nodeinfo:ou=Hosts,?one?objectClass=nodeInfo,\ nodeInventory=*:\ ou=Hosts,?one?objectClass=nodeInfo:\ dbid=nodeinfo_del

5. Create the rule set that maps nodeinfo data from NIS+ to LDAP. The template (from netmasks) is the following.

   nisplusLDAPattributeFromColumn \ netmasks: dn=("ipNetworkNumber=%s,", addr), \ ipNetworkNumber=addr, \ ipNetmaskNumber=mask, \ description=comment

   The ou=Hosts container has an additional complication in this case, as RFC 2307 specifies the dn should contain the IP address. However, the IP address is not stored in the nodeinfo table, so you must obtain it in another manner. Fortunately, the crednode mapping in the template file shows how to obtain the IP address.

   nisplusLDAPattributeFromColumn \ crednode: dn=("cn=%s+ipHostNumber=%s,", \ (cname, "%s.*"), \ ldap:ipHostNumber:?one?("cn=%s", (cname, "%s.*"))), \

   Thus, you can copy that portion of the crednode mapping. In this case, however, the cname column value is the actual host name (not the principal name), so you do not need to extract just a portion of the cname. Making the obvious substitutions of attribute and column names, the nodeinfo mapping becomes the following.

   nisplusLDAPattributeFromColumn \ nodeinfo: dn=("cn=%s+ipHostNumber=%s,", cname, \ ldap:ipHostNumber:?one?("cn=%s", cname)), \ nodeInventory=inventory, \ nodeOwner=owner

6. When mapping data from LDAP to NIS+, the template netmasks entry is as follows.

   nisplusLDAPcolumnFromAttribute \ netmasks: addr=ipNetworkNumber, \ mask=ipNetmaskNumber, \ comment=description

   After substituting attribute and column names, this result is the following.

   nisplusLDAPcolumnFromAttribute \ nodeinfo: cname=cn, \ inventory=nodeInventory, \ owner=nodeOwner

7. The delete rule set for netmasks is as follows.

   nisplusLDAPattributeFromColumn \ netmasks_del: dn=("ipNetworkNumber=%s,", addr), \ ipNetmaskNumber=

   The above specifies that when a netmasks entry is deleted in NIS+, the ipNetmaskNumber attribute in the corresponding ou=Networks LDAP entry is deleted. In this case, delete the nodeInventory and nodeOwner attributes. Therefore, using the dn specification from item (5) above, results in the following.

   nisplusLDAPattributeFromColumn \ nodeinfo_del: dn=("cn=%s+ipHostNumber=%s,", cname, \ ldap:ipHostNumber:?one?("cn=%s", cname)), \ nodeInventory=, \ nodeOwner=

8. The mapping information is complete. In order to begin using it, stop and later start the rpc.nisd daemon.

   # pkill rpc.nisd

9. If there already is data in the NIS+ nodeinfo table, upload that data to LDAP. Put the new nodeinfo mapping information into a separate file, /var/nis/tmpmapping.

   # /usr/sbin/rpc.nisd -D -m /var/nis/tmpmapping \

   -x nisplusLDAPinitialUpdateAction=to_ldap \

   -x nisplusLDAPinitialUpdateOnly=yes

10. Add the mapping information from the temporary file, /var/nis/tmpmapping, to the actual mapping file. Use an editor to do this, or append the data (assuming the actual mapping file is /var/nis/NIS+LDAPmapping) as follows.

    # cp -p /var/nis/NIS+LDAPmapping \

    /var/nis/NIS+LDAPmapping.backup

    # cat /var/nis/tmpmapping >> /var/nis/NIS+LDAPmapping

    ---

    Note –

    Note the double arrow redirection, ">>". A single arrow, ">", would overwrite the target file.

    ---

11. Restart the rpc.nisd daemon. Add the -Y option if the rpc.nisd daemon also serves NIS (YP) data as follows.

    # /usr/sbin/rpc.nisd -m /var/nis/NIS+LDAPmapping

Storing Configuration Information in LDAP

In addition to keeping NIS+/LDAP configuration information in the configuration files and on the command line, configuration attributes can also be stored in LDAP. This is useful if the configuration information is shared by many NIS+ servers, and is expected to change on a regular basis.

To enable storing of configuration attributes in LDAP, consult your LDAP server documentation and create the following new attributes and object class. The configuration information is expected to reside at the location specified by the nisplusLDAPconfigDN value (from the rpc.nisd command line, or from /etc/default/rpc.nisd), with a cn equal to the nisplusLDAPbaseDomain value (as it is known to the rpc.nisd daemon before reading any configuration information from LDAP).

LDIF data is suitable for ldapadd(1) (attribute and object class OIDs are examples only).

The defaultSearchBase, preferredServerList, and authenticationMethod attributes derive from a draft “DUA config” schema, which is intended to become an IETF standard. In any case, the following definitions are sufficient for the purposes of NIS+LDAPmapping(4).

dn: cn=schema
changetype: modify
add: attributetypes
attributetypes:	( 1.3.6.1.4.1.11.1.3.1.1.1 NAME 'defaultSearchBase' \
		  DESC 'Default LDAP base DN used by a DUA' \
		  EQUALITY distinguishedNameMatch \
		  SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 SINGLE-VALUE )
attributetypes:	( 1.3.6.1.4.1.11.1.3.1.1.2 NAME 'preferredServerList' \
		  DESC 'Preferred LDAP server host addresses to be used by a DUA' \
		  EQUALITY caseIgnoreMatch \
		  SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE )
attributetypes:	( 1.3.6.1.4.1.11.1.3.1.1.6 NAME 'authenticationMethod' \
		  DESC 'Identifies the authentication method used to connect to the DSA'\
		  EQUALITY caseIgnoreMatch \
		  SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE )

NIS+/LDAP configuration attributes are as follows.

dn: cn=schema
changetype: modify
add: attributetypes
attributetypes:	( 1.3.6.1.4.1.42.2.27.5.42.42.18.0 \
		  NAME 'nisplusLDAPTLS' \
		  DESC 'Transport Layer Security' \
		  SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )
attributetypes:	( 1.3.6.1.4.1.42.2.27.5.42.42.18.1 \
		  NAME 'nisplusLDAPTLSCertificateDBPath' \
		  DESC 'Certificate file' \
		  SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )
attributetypes:	( 1.3.6.1.4.1.42.2.27.5.42.42.18.2 \
		  NAME 'nisplusLDAPproxyUser' \
		  DESC 'Proxy user for data store/retrieval' \
		  SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )
attributetypes:	( 1.3.6.1.4.1.42.2.27.5.42.42.18.3 \
		  NAME 'nisplusLDAPproxyPassword' \
		  DESC 'Password/key/shared secret for proxy user' \
		  SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )
attributetypes:	( 1.3.6.1.4.1.42.2.27.5.42.42.18.4 \
		  NAME 'nisplusLDAPinitialUpdateAction' \
		  DESC 'Type of initial update' \
		  SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )
attributetypes:	( 1.3.6.1.4.1.42.2.27.5.42.42.18.5 \
		  NAME 'nisplusLDAPinitialUpdateOnly' \
		  DESC 'Exit after update ?' \
		  SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )
attributetypes:	( 1.3.6.1.4.1.42.2.27.5.42.42.18.6 \
		  NAME 'nisplusLDAPretrieveErrorAction' \
		  DESC 'Action following an LDAP search error' \
		  SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )
attributetypes:	( 1.3.6.1.4.1.42.2.27.5.42.42.18.7 \
		  NAME 'nisplusLDAPretrieveErrorAttempts' \
		  DESC 'Number of times to retry an LDAP search' \
		  SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )
attributetypes:	( 1.3.6.1.4.1.42.2.27.5.42.42.18.8 \
		  NAME 'nisplusLDAPretrieveErrorTimeout' \
		  DESC 'Timeout between each search attempt' \
		  SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )
attributetypes:	( 1.3.6.1.4.1.42.2.27.5.42.42.18.9 \
		  NAME 'nisplusLDAPstoreErrorAction' \
		  DESC 'Action following an LDAP store error' \
		  SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )
attributetypes:	( 1.3.6.1.4.1.42.2.27.5.42.42.18.10 \
		  NAME 'nisplusLDAPstoreErrorAttempts' \
		  DESC 'Number of times to retry an LDAP store' \
		  SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )
attributetypes:	( 1.3.6.1.4.1.42.2.27.5.42.42.18.11 \
		  NAME 'nisplusLDAPstoreErrorTimeout' \
		  DESC 'Timeout between each store attempt' \
		  SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )
attributetypes:	( 1.3.6.1.4.1.42.2.27.5.42.42.18.12 \
		  NAME 'nisplusLDAPrefreshErrorAction' \
		  DESC 'Action when refresh of NIS+ data from LDAP fails' \
		  SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )
attributetypes:	( 1.3.6.1.4.1.42.2.27.5.42.42.18.13 \
		  NAME 'nisplusLDAPrefreshErrorAttempts' \
		  DESC 'Number of times to retry an LDAP refresh' \
		  SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )
attributetypes:	( 1.3.6.1.4.1.42.2.27.5.42.42.18.14 \
		  NAME 'nisplusLDAPrefreshErrorTimeout' \
		  DESC 'Timeout between each refresh attempt' \
		  SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )
attributetypes:	( 1.3.6.1.4.1.42.2.27.5.42.42.18.15 \
		  NAME 'nisplusNumberOfServiceThreads' \
		  DESC 'Max number of RPC service threads' \
		  SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )
attributetypes:	( 1.3.6.1.4.1.42.2.27.5.42.42.18.16 \
		  NAME 'nisplusThreadCreationErrorAction' \
		  DESC 'Action when a non-RPC-service thread creation fails' \
		  SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )
attributetypes:	( 1.3.6.1.4.1.42.2.27.5.42.42.18.17 \
		  NAME 'nisplusThreadCreationErrorAttempts' \
		  DESC 'Number of times to retry thread creation' \
		  SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )
attributetypes:	( 1.3.6.1.4.1.42.2.27.5.42.42.18.18 \
		  NAME 'nisplusThreadCreationErrorTimeout' \
		  DESC 'Timeout between each thread creation attempt' \
		  SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )
attributetypes:	( 1.3.6.1.4.1.42.2.27.5.42.42.18.19 \
		  NAME 'nisplusDumpErrorAction' \
		  DESC 'Action when an NIS+ dump fails' \
		  SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )
attributetypes:	( 1.3.6.1.4.1.42.2.27.5.42.42.18.20 \
		  NAME 'nisplusDumpErrorAttempts' \
		  DESC 'Number of times to retry a failed dump' \
		  SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )
attributetypes:	( 1.3.6.1.4.1.42.2.27.5.42.42.18.21 \
		  NAME 'nisplusDumpErrorTimeout' \
		  DESC 'Timeout between each dump attempt' \
		  SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )
attributetypes:	( 1.3.6.1.4.1.42.2.27.5.42.42.18.22 \
		  NAME 'nisplusResyncService' \
		  DESC 'Service provided during a resync' \
		  SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )
attributetypes:	( 1.3.6.1.4.1.42.2.27.5.42.42.18.23 \
		  NAME 'nisplusUpdateBatching' \
		  DESC 'Method for batching updates on master' \
		  SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )
attributetypes:	( 1.3.6.1.4.1.42.2.27.5.42.42.18.24 \
		  NAME 'nisplusUpdateBatchingTimeout' \
		  DESC 'Minimum time to wait before pinging replicas' \
		  SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )
attributetypes:	( 1.3.6.1.4.1.42.2.27.5.42.42.18.25 \
		  NAME 'nisplusLDAPmatchFetchAction' \
		  DESC 'Should pre-fetch be done ?' \
		  SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )
attributetypes:	( 1.3.6.1.4.1.42.2.27.5.42.42.18.26 \
		  NAME 'nisplusLDAPbaseDomain' \
		  DESC 'Default domain name used in NIS+/LDAP mapping' \
		  SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )
attributetypes:	( 1.3.6.1.4.1.42.2.27.5.42.42.18.27 \
		  NAME 'nisplusLDAPdatabaseIdMapping' \
		  DESC 'Defines a database id for an NIS+ object' \
		  SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
attributetypes:	( 1.3.6.1.4.1.42.2.27.5.42.42.18.28 \
		  NAME 'nisplusLDAPentryTtl' \
		  DESC 'TTL for cached objects derived from LDAP' \
		  SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
attributetypes:	( 1.3.6.1.4.1.42.2.27.5.42.42.18.29 \
		  NAME 'nisplusLDAPobjectDN' \
		  DESC 'Location in LDAP tree where NIS+ data is stored' \
		  SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
attributetypes:	( 1.3.6.1.4.1.42.2.27.5.42.42.18.30 \
		  NAME 'nisplusLDAPcolumnFromAttribute' \
		  DESC 'Rules for mapping LDAP attributes to NIS+ columns' \
		  SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
attributetypes:	( 1.3.6.1.4.1.42.2.27.5.42.42.18.31 \
		  NAME 'nisplusLDAPattributeFromColumn' \
		  DESC 'Rules for mapping NIS+ columns to LDAP attributes' \
		  SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )

dn: cn=schema
changetype: modify
add: objectclasses
objectclasses:	( 1.3.6.1.4.1.42.2.27.5.42.42.19.0 NAME 'nisplusLDAPconfig' \
		  DESC 'NIS+/LDAP mapping configuration' \
		  SUP top STRUCTURAL MUST ( cn ) \
		  MAY ( preferredServerList $ defaultSearchBase $ 
authenticationMethod $ nisplusLDAPTLS $ nisplusLDAPTLSCertificateDBPath 
$ nisplusLDAPproxyUser $ nisplusLDAPproxyPassword $ nisplusLDAPinitialUpdateAction 
$ nisplusLDAPinitialUpdateOnly $ nisplusLDAPretrieveErrorAction 
$ nisplusLDAPretrieveErrorAttempts $ nisplusLDAPretrieveErrorTimeout 
$ nisplusLDAPstoreErrorAction $ nisplusLDAPstoreErrorAttempts 
$ nisplusLDAPstoreErrorTimeout $ nisplusLDAPrefreshErrorAction 
$ nisplusLDAPrefreshErrorAttempts $ nisplusLDAPrefreshErrorTimeout 
$ nisplusNumberOfServiceThreads $nisplusThreadCreationErrorAction 
$ nisplusThreadCreationErrorAttempts $ nisplusThreadCreationErrorTimeout 
$ nisplusDumpErrorAction $ nisplusDumpErrorAttempts 
$ nisplusDumpErrorTimeout $ nisplusResyncService $ nisplusUpdateBatching 
$ nisplusUpdateBatchingTimeout $ nisplusLDAPmatchFetchAction 
$ nisplusLDAPbaseDomain $ nisplusLDAPdatabaseIdMapping $ nisplusLDAPentryTtl 
$ nisplusLDAPobjectDN $ nisplusLDAPcolumnFromAttribute !
$ nisplusLDAPattributeFromColumn ) )

Create a file containing the following LDIF data (substitute your actual search base for searchBase, and the fully qualified domain name for domain.)

dn: cn=domain,searchBase

cn: domain

objectClass: top objectClass: nisplusLDAPconfig

Use the above file as input to ldapadd(1) to create the NIS+/LDAP configuration entry. Initially, the entry is empty. Use ldapmodify(1) to add configuration attributes. For example, to set the nisplusNumberOfServiceThreads attribute to "32", create the following file (for input to ldapmodify(1)).

dn: cn=domain, searchBasenisplusNumberOfServiceThreads: 32