LDAP to NIS Gateway
LDAP to NIS+ GatewayWhat Is a Gateway?A gateway is a service that provides a mapping of one type of data to another. In respect to naming services, a gateway is used to map NIS+ data to LDAP data. The NIS+ gateway maintains a copy of NIS+ data most of which is stored in a LDAP directory. The copy of the data is updated whenever the corresponding LDAP entries are updated. It can also be updated using the native naming service tools. To function transparently to clients , a modified version of the native server rpc.nisd , is used to service the clients. The modified server references a mapping file to determine how to store the native naming service data in LDAP and how to retrieve it so it can be presented to the client. The modified server is also responsible for maintaining cache consistency. The advantage of the new gateway over the previous NIS Extensions implementation is that the service is decoupled from any particular LDAP server. The NIS Extensions were implemented partly as a directory plug-in that only worked with a specific directory server version (Netscape Directory Server 4.1x). The process that provided the native naming service ( dsypservd ) had to run on the same system as the directory server. The new gateway technology uses a Solaris OE process that is a standalone process from the directory server process. This allows the gateway to run on a different server than the directory server, although you can run them on the same server if you want to. The only dependency is the operating environment. FIGURE 5-1 depicts what a gateway deployment might look like. Figure 5-1. Gateway Deployment In FIGURE 5-1, Client 1 is a native NIS+ client that communicates to Server A which is running the gateway software. In this case, only cached data is maintained on the server. When data updates occur, the cache is refreshed from the directory server that resides on Server B. The native NIS+ client called Client 2 communicates directly to a server where the directory server resides. The third client, Client 3, is running native LDAP and is accessing the same information the other clients are. NIS+ Gateway ComponentsFIGURE 5-1 shows how the gateway was implemented. The software for this service is contained in the following packages:
These packages also contain the software for native NIS and NIS+. They are loaded as part of the core installation, so should be available. However, to run the NIS+ Gateway software, a directory server must exist somewhere on the network. In theory, any LDAP v3-compliant directory server should work, but only the bundled Sun ONE directory Server software is discussed here. This is because several additional configuration steps are required to configure other directory servers, and those steps are beyond the scope of this book. There are only three visible components of the NIS+ Gateway software:
The same rpc.nisd process is used whether you are running the gateway or running native NIS+ without the gateway. The rpc.nisd process determines the configuration by the presence of the NIS+LDAPmapping file in the /var/nis directory. If a file with that exact name does not exist, the rpc.nisd process will not use the directory server as a back-end store. The /etc/default/rpc.nisd file contains information about what directory server to use and where to search for information it contains. There are many parameters that can be configured in this file, as described in a following section. The NIS+LDAPmapping file describes how the NIS+ data is mapped to LDAP attributes and object classes. The mapping file is quite complex, but in most deployments, only a slight modification is required. For reference, all the relevant parameters are described. Using the Gateway as a Transition ToolThe following tasks are recommended:
NIS+ servers remain NIS+ clients until their NIS+ server role is decommissioned, at which time they can be converted to be LDAP name service clients. Once the NIS+ master is the only remaining NIS+ client, it can be converted to be an LDAP client and the conversion is complete. The following sections examine the configuration files and the parameters they contain. rpc.nisd - Configuration File for NIS+ Service DaemonThe /etc/default/rpc.nisd file specifies configuration information for the rpc.nisd server. Configuration information can come from a combination of three places (listed in order of precedence):
Although many configuration parameters can be set, in most cases the defaults will work fine. Most of the parameters used in the /etc/default/rpc.nisd file have the same names as the corresponding LDAP attributes. Some of the initialization parameters do not have equivalents because they are used to locate and connect to the LDAP server to retrieve the configuration data. The parameters can be placed in three categories:
Each of these types is described in the following sections. Initialization ParametersThe following attributes are not part of the nisplusLDAPconfig object class and can only be set locally, either in rpc.nisd(4) , or from the command line. These are used only for loading configuration data from the LDAP server. If all the configuration data is set in NIS+LDAPmapping(4) and rpc.nisd(4) , these parameters need not be set. Note If the LDAP service is unavailable, rpc.nisd(1M) will wait until it can successfully read the configuration data before offering the NIS+ service.
Data Retrieval Parameters
The nisplusLDAPsearchTimeout limits the amount of time the client rpc.nisd waits for completion of a search operation, so setting the nisplusLDAPsearchTimeLimit larger than the nisplusLDAPsearchTimeout is not recommended.
The value of this attribute is a decimal integer from zero to (2**31)-1, inclusive. Zero, which is the default, sets the number of service threads to three plus the number of CPUs available when the rpc.nisd daemon starts. Example: nisplusNumberOfServiceThreads=16 Action- Related ParametersThe following attributes specify the action to be taken when some event occurs. The values are all of the form event=action. The default action is the first one listed for each event. Note A complete list of parameters is provided, although only the ones with *LDAP* in their names are directly related to the NIS+ to LDAP gateway.
Storing Configuration Attributes in LDAPMost attributes previously described, as well as those from the NIS+LDAPmapping (4) man page, can be stored in LDAP. In order to do so, you must add definitions to your LDAP server, which are described here in LDIF format, suitable for use by ldapadd (1). The attribute and object class OIDs are examples only. Using LDAP to Store Configuration DataExcept for the information required to locate and search an LDAP configuration server, the NIS+ Gateway configuration parameters can be stored in an LDAP directory. Most of the information is stored in the nisplusLDAPconfig object class, which is shown below. The nisplusLDAPconfig Object Class: NAME 'nisplusLDAPconfig' DESC 'NIS+/LDAP mapping configuration' 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 Most of the attributes that the nisplusLDAPconfig object class can contain are not included in any Sun ONE Directory Server schema files. The following attributes are also used by the DUAconfigProfile object class and are included when you run the idsconfig script to set up the directory server to support native LDAP clients.
The last six attributes shown in bold type in the example do not equate to configuration parameters in the /etc/default/rpc.nisd file. These are used to map data from NIS+ to LDAP and are described in "How NIS+ Data is Mapped to LDAP" on page 328. The following are the schema definitions for the attributes used in the nisplusLDAPconfig object class. These are included for reference only. If you choose to use LDAP to store configuration parameters, follow the instructions in "Configuring the Sun ONE Directory Server Software as a Configuration Server for rpc.nisd" on page 326. Attributes shared by DUAconfigProfile: NAME 'defaultSearchBase' DESC 'Default LDAP base DN used by a DUA' EQUALITY distinguishedNameMatch SYNTAX SINGLE-VALUE ) NAME 'preferredServerList' DESC 'Preferred LDAP server host addresses used by DUA' EQUALITY caseIgnoreMatch \ SYNTAX SINGLE-VALUE NAME 'authenticationMethod' \ DESC 'Authentication method used to contact the DSA' EQUALITY caseIgnoreMatch \ SYNTAX SINGLE-VALUE ) Attributes Requiring Configuration: NAME nisplusLDAPTLS DESC Transport Layer Security SYNTAX SINGLE-VALUE NAME nisplusLDAPTLSCertificateDBPath DESC Certificate file SYNTAX SINGLE-VALUE NAME 'nisplusLDAPproxyUser' DESC 'Proxy user for data store/retrieval' SYNTAX SINGLE-VALUE NAME 'nisplusLDAPproxyPassword' DESC 'Password/key/shared secret for proxy user' SYNTAX SINGLE-VALUE NAME 'nisplusLDAPbaseDomain' DESC 'Default domain name used in NIS+/LDAP mapping' SYNTAX SINGLE-VALUE Note These attributes can be set locally in /etc/default/rpc.nisd . Attributes Generally Not Requiring Configuration: NAME 'nisplusNumberOfServiceThreads' DESC 'Max number of RPC service threads' SYNTAX SINGLE-VALUE NAME 'nisplusThreadCreationErrorAction' \ DESC 'Action when a non-RPC-service thread creation fails' \ SYNTAX SINGLE-VALUE NAME 'nisplusThreadCreationErrorAttempts' DESC 'Number of times to retry thread creation' SYNTAX SINGLE-VALUE NAME 'nisplusThreadCreationErrorTimeout' DESC 'Timeout between each thread creation attempt' SYNTAX SINGLE-VALUE NAME 'nisplusDumpErrorAction' DESC 'Action when a NIS+ dump fails' SYNTAX SINGLE-VALUE NAME 'nisplusDumpErrorAttempts' DESC 'Number of times to retry a failed dump' SYNTAX SINGLE-VALUE NAME 'nisplusDumpErrorTimeout' DESC 'Timeout between each dump attempt' SYNTAX SINGLE-VALUE NAME 'nisplusResyncService' DESC 'Service provided during a resync' SYNTAX SINGLE-VALUE NAME 'nisplusUpdateBatching' DESC 'Method for batching updates on master' SYNTAX SINGLE-VALUE NAME 'nisplusUpdateBatchingTimeout' DESC 'Minimum time to wait before pinging replicas' SYNTAX SINGLE-VALUE ) Error Action Attributes: NAME 'nisplusLDAPinitialUpdateAction' DESC 'Type of initial update' SYNTAX SINGLE-VALUE NAME 'nisplusLDAPinitialUpdateOnly' DESC 'Exit after update ?' SYNTAX SINGLE-VALUE NAME 'nisplusLDAPretrieveErrorAction' \ DESC 'Action following an LDAP search error' SYNTAX SINGLE-VALUE ) NAME 'nisplusLDAPretrieveErrorAttempts' DESC 'Number of times to retry an LDAP search' SYNTAX SINGLE-VALUE NAME 'nisplusLDAPretrieveErrorTimeout' DESC 'Timeout between each search attempt' SYNTAX SINGLE-VALUE NAME 'nisplusLDAPstoreErrorAction' DESC 'Action following an LDAP store error' SYNTAX 26 SINGLE-VALUE NAME 'nisplusLDAPstoreErrorAttempts' DESC 'Number of times to retry an LDAP store' SYNTAX SINGLE-VALUE NAME 'nisplusLDAPstoreErrorTimeout' DESC 'Timeout between each store attempt' SYNTAX SINGLE-VALUE NAME 'nisplusLDAPrefreshErrorAction' DESC 'Action when refresh of NIS+ data from LDAP fails' SYNTAX SINGLE-VALUE NAME 'nisplusLDAPrefreshErrorAttempts' DESC 'Number of times to retry an LDAP refresh' SYNTAX SINGLE-VALUE NAME 'nisplusLDAPrefreshErrorTimeout' DESC 'Timeout between each refresh attempt' SYNTAX SINGLE-VALUE Attributes Used for Mapping Data: NAME 'nisplusLDAPmatchFetchAction' DESC 'Should pre-fetch be done ?' SYNTAX SINGLE-VALUE NAME 'nisplusLDAPdatabaseIdMapping' DESC 'Defines a database id for a NIS+ object' SYNTAX NAME 'nisplusLDAPentryTtl' DESC 'TTL for cached objects derived from LDAP' SYNTAX NAME 'nisplusLDAPobjectDN' DESC 'Location in LDAP tree where NIS+ data is stored' SYNTAX NAME 'nisplusLDAPcolumnFromAttribute' DESC 'Rules for mapping LDAP attributes to NIS+ columns' SYNTAX NAME 'nisplusLDAPattributeFromColumn' DESC 'Rules for mapping NIS+ columns to LDAP attributes' SYNTAX Configuring the Sun ONE Directory Server Software as a Configuration Server for rpc.nisdThe basic tasks for configuring the Sun ONE Directory Server software are:
Task 1 To Update the Schema
Task 2 To Create a Configuration Entry
Task 3 To Modify rpc.nisd
Note The example shown here uses a simple LDAP bind. This is only recommended if rpc.nisd and the directory server are running on the same server. How NIS+ Data is Mapped to LDAPTo be able to access the same data from both NIS+ clients and LDAP clients, the data NIS+ tables need to be represented as LDAP object classes and attributes. The object classes for the most part have been defined in RFC 2307, which is the same data structure used to map NIS data. However, because you may wish to store NIS+ data that does not have an NIS counterpart , additional object classes and attributes might need to be defined. The mapping of NIS+ data to LDAP is not a one-to-one relation. That is, the rows and columns of NIS+ tables are not translated directly into LDAP attributes. If this were the case, a generic LDAP representation of NIS+ tables could be used for all data. Implementing mapping that way would not leverage the power of LDAP, because one of its strengths is the ability to deal with complex data. In most cases, the default mappings work fine. Default mappings are defined in a file called /var/nis/NIS+LDAPmapping.template . The defaults can be overwritten by configuration data stored in LDAP, or by command-line arguments specified when rpc.nisd (1M) is started. To start the mapping function, rpc.nisd looks for the presence of a /var/nis/NIS+LDAPmapping file. An alternative file can be referenced by specifying the -m switch. Not all NIS+ table entry mappings are defined in the RFC 2307bis specification, so additional schema definitions must be added to your directory server. These schema definitions include:
Additional Schema DefinitionsIn this section, sample schema definitions are provided in LDIF format that you can import into the Sun ONE Directory Server software using ldapmodify or ldapadd . You can obtain the sample schemas from the addSchema.ldif file available from the ldap-schemas.tar.gz downloadable file (see "Obtaining the Downloadable Files for This Book" on page xxvii). If you choose not to deploy these additional schema definitions, it does not mean they will not be available to NIS+ clients. The information will still be available in the data cache, but it will not be stored in LDAP. timezone SchemaIf you choose to maintain time zone information in LDAP, your directory server needs to be configured with an additional schema definition. After the schema definition is added, you must uncomment the lines referring to timezone in the NIS+LDAPmapping file to activate LDAP storage of the information. Below is the LDIF representation of the nisplusTimeZone attribute and the nisplusTimeZoneData object class. 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 ) ) Below is a sample LDIF to create the container for the time zone data. dn: ou=Timezone,dc=example,dc=com ou: Timezone objectClass: top objectClass: organizationalUnit client_info SchemaIf you wish to store the client_info table in LDAP, you need to update your directory server schema files. After you update the schema, you need to uncomment the lines referring to client_info in the NIS+LDAPmapping file to activate the LDAP storage of this information. The schema for client_info attributes and object classes in LDIF format is: 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)) Sample LDIF to create the container. dn: ou=ClientInfo,dc=example,dc=com ou: ClientInfo objectClass: top objectClass: organizationalUnit NIS+ Object Data and Entry DataThe NIS+ naming service stores information about the NIS+ objects themselves , in addition to the entries they contain. This information can be used to set ownership and access rights of the objects. LDAP provides its own mechanism for defining object access rights, so the information is not applicable in LDAP. You might wish to replicate this information to another NIS+ Gateway over LDAP, so storing the information in LDAP might be useful. The default NIS+LDAPmapping(4) file assumes that NIS+ objects will be mapped, so no additional steps are required to activate it. However, as the sample deployment illustrates, you need to comment out lines in NIS+LDAPmapping to avoid having to add the additional schema definition. The following is an LDIF representation for adding the NIS+ object schema. 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 a 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 a NIS+ object' \ MUST ( cn $ nisplusObject ) ) The following is an LDIF representation that can be imported to create the container. dn: ou=nisPlus,dc=example,dc=com ou: nisPlus objectClass: top objectClass: organizationalUnit Associated with object data is information about ownership, access rights and time to live. The NIS+ Gateway makes assumptions about what this data should be based on the information stored about the object itself. In most cases, it is not necessary to change this behavior. The following shows the LDIF representation of the nisplusEntryData object class and its associated attributes. 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 ) ) Principal Names and NetnamesPrincipal names and the secure RPC equivalent netnames are used by NIS+ for authentication. While the RFC 2307 specification provides a mapping for public and private keys, there is no provision for storing principal or netnames. This information is maintained in the NIS+ cred.org_dir table, for which there is no standard LDAP counterpart. To get around this issue, the NIS+ Gateway makes some assumptions about how principal names and netnames should be constructed. Basically, the name is constructed by appending the domain name to either the user UID or host nodename. In most cases this works fine. The schema definition for principled names and netnames is shown below. 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' \ EQUALITY caseIgnoreIA5Match 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' \ EQUALITY caseIgnoreIA5Match SINGLE-VALUE \ YNTAX 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 ) ) NIS+ to LDAP MappingThe /var/nis/NIS+LDAPmapping file controls how NIS+ data is mapped to LDAP attributes and how LDAP attributes are mapped to NIS+ data. At first glance, the syntax of the file can be quite daunting. In practice, however, usually only minor changes are required. In this section, the syntax of the file is examined to give you a better understanding of how the mapping takes place. The NIS+LDAPmapping file contains five directives, which are:
nisplusLDAPdatabaseIdMapping DirectiveThis is an identifier the NIS+ Gateway uses to establish a relationship between an NIS+ object and a label the gateway uses internally. In some cases, the label is used to identify more than one NIS+ object, such as a table object and directory object. All the standard NIS+ objects have IDs assigned. Example: nisplusLDAPdatabaseIdMapping passwd:passwd.org_dir nisplusLDAPdatabaseIdMapping group:group.org_dir nisplusLDAPdatabaseIdMapping auto_master:auto_master.org_dir nisplusLDAPdatabaseIdMapping auto_home:auto_home.org_dir nisplusLDAPdatabaseIdMapping bootparams:bootparams.org_dir nisplusLDAPentryTtl DirectiveThis parameter specifies the time-to-live (TTL) for the rpc.nisd cache. There are three values associated with each database ID. The first two values represent a range of time in seconds that rpc.nisd randomly picks from when the object is initialized . The third value is used for subsequent cache refreshes. A random time is selected to prevent all objects from refreshing at the same time. The following are examples: nisplusLDAPentryTtl passwd:1800:3600:3600 nisplusLDAPentryTtl group:1800:3600:3600 nisplusLDAPentryTtl auto_master:1800:3600:3600 nisplusLDAPentryTtl auto_home:1800:3600:3600 nisplusLDAPentryTtl bootparams:1800:3600:3600 nisplusLDAPentryTtl ethers:1800:3600:3600 nisplusLDAPentryTtl hosts:1800:3600:3600 nisplusLDAPobjectDN DirectiveThis parameter specifies where in the DIT NIS+ object data resides. If the DN ends with a trailing comma, the value of the defaultSearchBase parameter (set in the rpc.nisd configuration) is appended to it. There are three action fields that determine:
If the third action field is left out, the default action is to delete the entire entry. Below is an example. Example: nisplusLDAPobjectDN hosts:ou=Hosts,?one?objectClass=ipHost:\ ou=Hosts,?one?objectClass=ipHost,\ objectClass=device,objectClass=top Note Because where to read the data from and where to write it to is the same, the write location can be omitted as long as the colon is present. The action is shown as an LDAP search filter. The hosts:ou=Hosts,?one?objectClass=ipHost is read as follows ( assuming the domain is example.com ):
The write action is the same as the read. The delete action is the default. That is, delete the entire entry. nisplusLDAPattributeFromColumn DirectiveThis directive is used to specify rules for mapping NIS+ data to LDAP. For example: nisplusLDAPattributeFromColumn \ hosts: dn=("cn=%s+ipHostNumber=%s,", cname, addr), \ cn=cname, \ cn=name, \ ipHostNumber=addr, \ description=comment In this example, the relative distinguished name (RDN) of the LDAP entry would be the cn= attribute with the value of the NIS+ cname (canonical name) attribute, followed by the string +ipHostNumber= , then the value of the NIS+ addr attribute. The entry contains a cn attribute with the value of cname and if the host name has an alias, another cn attribute with the alias name. The IP address is assigned to the ipHostNumber attribute and if a comment field exists, the value of it is assigned to the description attribute. For example, if the NIS+ entry looks like this: # niscat -h hosts.org_dir # cname name addr comment localhost localhost 127.0.0.1 esso mailserver 10.10.9.12 #Mail server for Bldg 1 . . . The corresponding LDAP entry looks like this: dn: cn=esso+ipHostNumber=10.10.9.12,\ ou=Hosts,dc=example,dc=com objectClass: ipHost objectClass: device objectClass: top cn: esso cn: mailserver ipHostNumber: 10.10.9.12 description:Mail server for Bldg 1 nisplusLDAPcolumnFromAttribute DirectiveThis directive performs the opposite action of the nisplusLDAPattributeFromColumn directive. That is, it defines the rules to map LDAP data to NIS+. For example: nisplusLDAPcolumnFromAttribute \ hosts: cname=cn, \ (name)=(cn), \ addr=ipHostNumber, \ comment=description Using the Default Configuration FilesIn most cases you will want to change some of the default configuration parameters. However, you can run the NIS+ Gateway without any modifications to the configuration files. A list of assumptions is presented here to help you gauge how much modification will be required to fit your environment. Assumptions
Common Configuration ChangesThe following is a list of changes that you probably will want to make.
NIS+ to LDAP Migration ExampleThe NIS+ Gateway is very flexible, providing many different ways to configure it to meet your needs. Providing examples that cover all the different possible configurations would be very long and would be more confusing than beneficial. Therefore, the following assumptions are made about the environment where the NIS+ Gateway is run.
To Migrate Your Data From NIS+ to LDAPBefore proceeding, make sure you backup all NIS+ data; see nisbackup(1M) .
Testing and Troubleshooting the NIS+ GatewayBefore uploading all your NIS+ data to the LDAP server, it is wise to test out the mapping you established. This should be done before you rename the configuration file to NIS+LDAPmapping and restart rpc.nisd , which activates the NIS+ Gateway. The following assumes you have a group in your NIS+ database called gem . The nisldapmaptest command is run in the verbose mode to give you a clearer idea of what the command is doing. # nisldapmaptest -v -r -m nls -t group.org_dir name=gem createQuery: NIS+ query: [name=gem]group.org_dir.example.com. mapToLDAP: group.org_dir.example.com.: 1 * 1 potential updates mapToLDAP: group.org_dir.example.com.: 1 update requested controlSupported: 127.0.0.1: 1.2.840.113556.1.4.319: disabled controlSupported: 127.0.0.1: 2.16.840.1.113730.3.4.9: enabled mapToLDAP: group.org_dir.example.com.: 1 update performed As you can observe from the last line the update was performed. To verify this, you can run the ldapsearch command as shown in the following example. # ldapsearch -b dc=example,dc=com cn=gem cn=gem,ou=Group,dc=example,dc=com cn=gem gidNumber=2292 objectClass=posixGroup objectClass=top To remove test entries: # ldapsearch -b dc=example,dc=com cn=gem dn cn=gem,ou=Group,dc=example,dc=com # ldapdelete -D "cn=directory manager" -w mypass cn=gem,ou= Group,dc=example,dc=com Once the NIS+ Gateway is activated, you can test it by creating an entry in LDAP and see if it appears in NIS+. # vi /tmp/hosts.ldif dn: cn=test1+ipHostNumber=10.10.9.12,ou=Hosts,dc=example,dc=com cn: test1 ipHostNumber: 10.10.9.12 objectClass: ipHost objectClass: device objectClass: top # ldapmodify -a -D "cn=directory manager" -f /tmp/hosts.ldif Bind Password: adding new entry cn=test1+ipHostNumber=10.10.9.12,ou=Hosts,dc= example,dc=com # After a few seconds, you should be able to see the new entry from NIS+ as shown in this example. # niscat hosts.org_dir grep test1 test1 test1 10.10.9.12 Troubleshooting TipsMost errors are the result of misconfigured rpc.nisd or NIS+LDAPmapping files. If you encounter problems, follow these steps:
Common Problems
 |
![LDAP in the Solaris Operating Environment[c] Deploying Secure Directory Services](/icons/blank_book.jpg "LDAP in the Solaris Operating Environment[c] Deploying Secure Directory Services"){kind=icon}
EAN: N/A
Pages: 87