This chapter describes how to make the transition from using the NIS+ naming service to LDAP naming services. LDAPtransitioning from NIS+ toThe 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.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 (NIS+ to LDAP) 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 /etc/default/rpc.nisd file is used to select LDAP server and authentication, and controls some general rpc.nisd behavior. See rpc.nisd4. The details of the mapping are specified via the /var/nis/NIS+LDAPmapping file. For more information, see NIS+LDAPmapping4. The name of the mapping file can be changed by editing the /lib/svc/method/nisplus file. See NIS+ to LDAP Tools and the Service Management Facility for more information.The following terms are used in this chapter.ContainerA 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. NetnameA netname is an entity in secure RPC (user or machine) that can be authenticated. MappingMapping 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). PrincipalA 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. rpc.nisd configuration filesTwo configuration files control rpc.nisd operation./etc/default/rpc.nisdThis 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+LDAPmappingThis 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 (NIS+ to LDAP) and NIS+LDAPmapping4. 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.rpc.nisd x option Configuration file LDAP New FeaturesService Management Facility with NIS+ to LDAP Service Management Facilityand NIS+ to LDAP NIS+ to LDAPService Management Facility Most of the command line administrative tasks associated with the NIS+ to LDAP transition are managed by the Service Management Facility. For an overview of SMF, refer to Chapter 16, Managing Services (Overview), in System Administration Guide: Basic Administration. Also refer to the svcadm1M and svcs1 man pages for more details.Administrative actions on the NIS+ to LDAP transition service, such as enabling, disabling, or restarting, can be performed using the svcadm command.Temporarily disabling a service by using the t option provides some protection for the service configuration. If the service is disabled with the t option, the original settings would be restored for the service after a reboot. If the service is disabled without t, the service will remain disabled after reboot. The NIS+ Fault Managed Resource Identifier (FMRI) is svc:/network/rpc/nisplus:<instance>. The FMRI for the LDAP client service is svc:/network/ldap/client:<instance>. You can query the status of NIS+ by using the svcs command.Example of svcs command and output. # svcs \*nisplus\* STATE STIME FMRI online Sep_01 svc:/network/rpc/nisplus:default Example of svcs l command and output. To get the output shown below, you must use the instance name in the FMRI.# svcs l network/rpc/nisplus:default fmri svc:/network/rpc/nisplus:default enabled false state disabled next_state none restarter svc:/system/svc/restarter:default dependency require_all/none svc:/network/rpc/keyserv (online) You can check a daemon's presence by using the ps command.# ps e | grep rpc.nisd root 23320 1 0 Aug 27 ? 16:30 ./ns-slapd -D \ /usr/iplanet/ds5/slapd-lastrev -i /usr/iplanet/ds5/slapd-lastrev/ root 25367 25353 0 15:35:19 pts/1 0:00 grep slapdDo not use the f option with ps because this option attempts to translate user IDs to names, which causes more naming service lookups that might not succeed. Service Management Facilityand NIS+ to LDAPwhen not to use SMF NIS+ to LDAPService Management Facilitywhen not to use SMF In general, the /usr/sbin/rpc.nisd daemon is administered using the svcadm command. However, when rpc.nisd is invoked with x nisplusLDAPinitialUpdateOnly=yes, rpc.nisd performs the specified initial update action, then exits. That is, rpc.nisd does not daemonize. The Service Management Facility should not be used in conjunction with x nisplusLDAPinitialUpdateOnly=yes. SMF can be used any other time you want to start, stop, or restart the rpc.nisd daemon.The following example shows rpc.nisd used with x nisplusLDAPinitialUpdateOnly=yes.# /usr/sbin/rpc.nisd m mappingfile \ x nisplusLDAPinitialUpdateAction=from_ldap \ x nisplusLDAPinitialUpdateOnly=yes /lib/svc/method/nisplus file If you want to include specific options when you invoke the rpc.nisd daemon with the Service Management Facility, you can use the svcprop command or modify the /lib/svc/method/nisplus file. See the svcprop1 man page for more information about using the svcprop command. The following procedure describes how to modify the /lib/svc/method/nisplus file.Become superuser or assume an equivalent role.Roles contain authorizations and privileged commands. For more information about roles, see Chapter 9, Using Role-Based Access Control (Tasks), in System Administration Guide: Security Services. Stop the NIS+ service.# svcadm disable network/rpc/nisplus:default Open the /lib/svc/method/nisplus file.Use the editor of your choice. Edit the file to add the desired options.Change:if [ -d /var/nis/data -o -d /var/nis/$hostname ]; then /usr/sbin/rpc.nisd || exit $To:if [ -d /var/nis/data -o -d /var/nis/$hostname ]; then /usr/sbin/rpc.nisd -Y -B || exit $?In this example, the Y and B options are added to rpc.nisd, so the options are automatically implemented at startup. Save and quit the /lib/svc/method/nisplus file. Start the NIS+ service.# svcadm enable network/rpc/nisplus:default 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 ldapadd1.# ldapadd D bind-DN f ldif fileThis method works with Sun Java System Directory Server, 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. For an introduction to the configuration needed to start using an LDAP repository for NIS+ data, see NIS+LDAPmapping4. The remainder of this section goes into more detail about the organization of the configuration files.All assignments in the /etc/default/rpc.nisd file are of the attributeName=value type.rpc.nisd attributes 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.nisd4 for more information.nisplusNumberOfServiceThreads nisplusThreadCreationErrorAction nisplusThreadCreationErrorAttempts nisplusThreadCreationErrorTimeout nisplusDumpErrorAction nisplusDumpErrorAttempts nisplusDumpErrorTimeout nisplusResyncService nisplusUpdateBatching nisplusUpdateBatchingTimeout 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.nisd4 for more information.nisplusLDAPconfigDN nisplusLDAPconfigPreferredServerList nisplusLDAPconfigAuthenticationMethod nisplusLDAPconfigTLS nisplusLDAPconfigTLSCertificateDBPath nisplusLDAPconfigProxyUser nisplusLDAPconfigProxyPassword preferredServerListSpecify 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 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 Optionally use SSL, and specify the location of the certificate file. See Using SSL for more information. defaultSearchBaseThe 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 Attribute for more information. nisplusLDAPbaseDomainThe default NIS+ domain name to use when NIS+ object specifications (see nisplusLDAPdatabaseIdMapping Attribute) are not fully qualified. 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.nisplusLDAPsearchSizeLimitThe 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. nisplusLDAPfollowReferralThe 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. 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.nisd4 for more information.nisplusLDAPinitialUpdateAction nisplusLDAPinitialUpdateOnly nisplusLDAPretrieveErrorAction nisplusLDAPretrieveErrorAttempts nisplusLDAPretrieveErrorTimeout nisplusLDAPstoreErrorAction nisplusLDAPstoreErrorAttempts nisplusLDAPstoreErrorTimeout nisplusLDAPrefreshErrorAction nisplusLDAPrefreshErrorAttempts nisplusLDAPrefreshErrorTimeout nisplusLDAPmatchFetchActionThe 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.nisd4 for more information. The presence of the default NIS+LDAPmapping file serves as a master switch for NIS+/LDAP mapping.If you use a non-default mapping file, you will have to edit the /lib/svc/method/nisplus script to specify the mapping file name on the rpc.nisd line by using the m mappingfile option. See NIS+ to LDAP Tools and the Service Management Facility for more information.For each NIS+ object that should be mapped to 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.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_dirdefines 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_dirdefines 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. 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:43200When 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:3600Each 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.nisddaemon 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. 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=topThe 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=nisplusObjectContainerNote 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=topThe 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_delThe 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 Attribute for more information. nisplusLDAPattributeFromColumn specifies the rules used to map NIS+ data to LDAP. Mapping rules for the other direction is controlled by nisplusLDAPcolumnFromAttribute. nisplusLDAPcolumnFromAttribute specifies the rules used to map LDAP data to NIS+.The full entry mapping syntax can be found on NIS+LDAPmapping4. 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+ serverAssuming the defaultSearchBase value is dc=some,dc=domain, the corresponding LDAP entry, as listed by ldapsearch1, would be the following.dn: cn=nisd,ou=Ppc,dc=some,dc=domain cn: nisd cn: rpc.nsid cn: nisplusd oncRpcNumber: 100300 description: NIS+ server objectClass: oncRpcThis 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=commentThis 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=domainThe 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=descriptionThe 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. 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. 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=yesThe 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.nisd4. 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=yesThe 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.nisd4. 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 nisaddent1M. 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 niscat1, you can use nistbladm1 to load entries back into NIS+ one by one. Your command path includes /usr/lib/nis (which is where nisaddent1M resides). 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. Back up all NIS+ data using the nisbackup command.# nisbackup -a /nisbackup 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_dir by using nisaddent as follows.# nisaddent -d group | sort > /before/groupPiping the nisaddent output to sort will make for convenient comparison later on. Stop the NIS+ service.# svcadm disable network/rpc/nisplus:default Download LDAP data to NIS+.# /usr/sbin/rpc.nisd -D -m tmpmap \ -x nisplusLDAPinitialUpdateAction=from_ldap \ -x nisplusLDAPinitialUpdateOnly=yes Start the NIS+ service.# svcadm enable network/rpc/nisplus:defaultThe 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. Dump the NIS+ data for the affected tables.The following example uses the group.org_dir table.# nisaddent -d group | sort > /after/group Create merged versions of the tables.Use the file merge procedure of your choice to produce the merged tables. If no other tools are available, you can use diff1 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. Load the merged data into NIS+. The following example uses the group table.# nisaddent -m -f /after/group group 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 ldapsearch1 to generate a list of entries for each container. For example, to generate a list of all entries in the ou=Rpc container, use ldapsearch1 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-dnSee 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/nullD. Repeat the above procedure for each container that has at least one entry which must be removed. Upload the merged NIS+ data to LDAP.Stop the NIS+ service.# svcadm disable network/rpc/nisplus:default Perform the upload.# /usr/sbin/rpc.nisd -D -m tmpmap \ -x nisplusLDAPinitialUpdateAction=to_ldap \ -x nisplusLDAPinitialUpdateOnly=yes (Optional) Modify the /lib/svc/method/nisplus file as needed.If the rpc.nisd daemon uses the LDAP repository, specify an appropriate mapping file with the m mappingfile option, if the default /var/yp/NIS+LDAPmapping file is not used. If the rpc.nisd daemon provides NIS (YP) emulation, specify the Y option by using svcprop or by modifying the /lib/svc/method/nisplus file. See NIS+ to LDAP Tools and the Service Management Facility for more information. Start the NIS+ service.# svcadm enable network/rpc/nisplus:default mastersreplicasOnly 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. When an NIS+ replica is obtaining data for at least one object in a particular NIS+ directory from LDAP, the update timestamps printed by nisping1M 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 dir1Master 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 2002The 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. directory serverThe 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+LDAPmapping4, 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.Refer to the Sun Java System Directory Server Collection for detailed instructions on the installation, setup and administration of Sun Java System Directory Server.You can use idsconfig1M to configure Sun Java System Directory Server for LDAP clients using LDAP as a naming service. The setup provided by idsconfig1M is also appropriate when using NIS+ with an LDAP data repository.If you are using an LDAP server other than Sun Java System Directory Server, you must manually configure the server to support the RFC 2307 schemas. 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 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.noneThe 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.simpleThe 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=awordBe 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 ps1. sasl/digest-md5The 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=awordBe sure to protect the file where the password is stored from unauthorized access. sasl/cram-md5Authentication 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=awordBe sure to protect the file where the password is stored from unauthorized access. 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.dbBe 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. When the rpc.nisd daemon is asked to enumerate an NIS+ table (using niscat1 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/nullwhereserver-addressIP address portion of preferredServerList value from /etc/default/rpc.nisd bind-DNnisplusLDAPproxyUser value from /etc/default/rpc.nisd passwordnisplusLDAPproxyPassword value from /etc/default/rpc.nisd containerOne of the RFC 2307 container names (ou=Services, ou=Rpc, and so on) search-basedefaultSearchBase 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. 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+LDAPmapping4) to remove the following attribute values for all non-table-entry objects.nisplusLDAPdatabaseIdMapping nisplusLDAPentryTtl nisplusLDAPobjectDNFor 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_dirnisplusLDAPdatabaseIdMapping 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 ldapadd1. 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: objectclassesobjectclasses: (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 ldapadd1.dn: ou=nisPlus,dc=some,dc=domain ou: nisPlus objectClass: top objectClass: organizationalUnit 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.nispasswdd1M 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.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: objectclassesobjectclasses:(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 ) ) 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=topEdit 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 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_accessSimilarly, 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 Upload owner, group, access, and/or TTL entry data to LDAP.See How to Convert All NIS+ Data to LDAP in One Operation for more information. Restart the NIS+ service in order to make the mapping change take effect.# svcadm restart network/rpc/nisplus:default principal namesnetnamesNIS+ 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 NIS+ service. Do not forget to edit the /lib/svc/method/nisplus file to include the m and Y options, or use the svcprop command, as appropriate. See NIS+ to LDAP Tools and the Service Management Facility for more information.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.# svcadm restart network/rpc/nisplus:default# pkill rpc.nisd 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.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 ldapadd1. 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, searchBaseobjectClass: organizationalUnitou: ClientInfoobjectClass: topUse 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 cifileDepending 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.# svcadm restart network/rpc/nisplus:defaultIf necessary, synchronize NIS+ and LDAP data as described in NIS+ to LDAP Migration Scenarios. 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 ldapadd1. 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: topobjectClass: organizationalUnitUse the above file as input to ldapadd1 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 tzfileDepending 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 the rpc.nisd daemon.# svcadm restart network/rpc/nisplus:defaultIf necessary, synchronize NIS+ and LDAP data as described in NIS+ to LDAP Migration Scenarios. object mappingsadding newThe 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.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. 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 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 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=topSince NIS+ replicas do not write data to LDAP, you can use the nisplusLDAPobjectDN above for both master and replicas. (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 nisldapmaptest1M utility, as you can leave the rpc.nisd daemon running.# nisldapmaptest m /var/nis/NIS+LDAPmapping o t nodeinfo rThe o option specifies the table object itself, not the table entries. 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=nodeinfoThe output would appear similar to the following.dn: cn=nodeinfo,ou=nisPlus,dc=some,dc=domain objectclass: nisplusObjectContainer objectclass: top cn: nodeinfo nisplusobject=<base 64 encoded data> Restart the NIS+ service.The service will start by using the new mapping information. Do not forget to edit the /lib/svc/method/nisplus file to add the m and Y options, or use the svcprop command, as appropriate. See NIS+ to LDAP Tools and the Service Management Facility for more information.# svcadm restart network/rpc/nisplus:default NIS+LDAPmapping4 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.Create a database id that identifies the NIS+ table to be mapped.nisplusLDAPdatabaseIdMapping nodeinfo:nodeinfo 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 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. 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_delTransferred 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 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=commentThe 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 When mapping data from LDAP to NIS+, the template netmasks entry is as follows.nisplusLDAPcolumnFromAttribute \ netmasks: addr=ipNetworkNumber, \ mask=ipNetmaskNumber, \ comment=descriptionAfter substituting attribute and column names, this result is the following.nisplusLDAPcolumnFromAttribute \ nodeinfo: cname=cn, \ inventory=nodeInventory, \ owner=nodeOwner 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=The mapping information is complete. The mapping information is complete. In order to begin using it, stop and later start the rpc.nisd daemon.# pkill rpc.nisd Stop, and later start, the NIS+ service, to begin using the mapping file.# svcadm disable network/rpc/nisplus:default If data is already 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 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+LDAPmappingNote the double arrow redirection, “>>”. A single arrow, “>”, would overwrite the target file. Add the m option to the /lib/svc/method/nisplus file. Also add the Y or B options as needed. See NIS+ to LDAP Tools and the Service Management Facility for more information. Start the NIS+ service.# svcadm enable network/rpc/nisplus:default 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 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 /lib/svc/method/nisplus), 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 ldapadd1 (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+LDAPmapping4.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 $ nisplusLDAPTLSCertificateDBPate $ 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,searchBasecn: domainobjectClass: top objectClass: nisplusLDAPconfigUse the above file as input to ldapadd1 to create the NIS+/LDAP configuration entry. Initially, the entry is empty. Use ldapmodify1 to add configuration attributes. For example, to set the nisplusNumberOfServiceThreads attribute to “32”, create the following file (for input to ldapmodify1).dn: cn=domain, searchBase nisplusNumberOfServiceThreads: 32