Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
How NIS+ Data is Mapped to LDAP
To 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 can be added to your directory server. These schema definitions include:
timezone attributes and object classes
client_info attributes and object classes
NIS+ object data
Principals and netnames
Non-standard data
NOTE
If you choose not to deploy 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 Schema
If 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 Schema
If 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.0NAME 'nisplusClientInfoAttr'
Sample LDIF to create the container.
dn: ou=ClientInfo,dc=example,dc=com ou: ClientInfo objectClass: top objectClass: organizationalUnit
NIS+ Object Data and Entry Data
The 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
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
Principal Names and Netnames
Principal 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 is 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
NIS+ to LDAP Mapping
The /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
nisplusLDAPentryTtl
nisplusLDAPobjectDN
nisplusLDAPattributeFromColumn
nisplusLDAPcolumnFromAttribute
nisplusLDAPdatabaseIdMapping Directive
This is an identifier the NIS+ Gateway uses establish a relation 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 Directive
This 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 Directive
This 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:
Where to read data from
Where to write data to
What to do if the LDAP data is deleted
If the third action field is left out, the default action is to delete the entire entry. Below ia an example.
Example:
nisplusLDAPobjectDN
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):
Start the search as ou=Hosts,dc=example,dc=com
Perform a one-level search (do not search below ou=Hosts).
Search only for entries that contain the object class of ipHost.
The write action is the same as the read. The delete action is the default. That is, delete the entire entry.
nisplusLDAPattributeFromColumn Directive
This directive is used to specify rules for mapping NIS+ data to LDAP. For example:
nisplusLDAPattributeFromColumn hosts:
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,
nisplusLDAPcolumnFromAttribute Directive
This 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,
Using the Default Configuration Files
In 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
The directory server is running on the same server as the NIS+ Gateway. That is, the server IP address is set to 127.0.0.1 and the port number is 389.
The NIS+ standard directories and tables are to be mapped, with the exception of timezone.org_dir and client_info.org_dir. This implies that the schema to hold the NIS+ table objects (nisObjectContainer) needs to be defined on the directory server. The schema definitions for timezone and client_info do not need to be defined.
The mapping is two way—that is, from NIS+ to LDAP and from LDAP to NIS+. This configuration allows updates to be made from either service.
The authentication method defined is none. This implies anonymous access to the directory and there is no transport layer security.
The directory server supports the RFC2307bis schema. This is the default configuration for the Sun ONE Directory Server software.
Only the entry values are mapped. Information contained in pseudo-columns such as table owner and group is not mapped.
The default NIS+ credentials are sufficient.
The configuration data will not be maintained in LDAP.
Common Configuration Changes
The following is a list of changes that you probably will want to make.
Directory Server address and port number.
Authentication Method:
The bind-DN to use for authentication:
Transport Security:
Time-to-Live Parameters
NIS+ Table Object Support
In the rpc.nisd file, change: preferredServerList=127.0.0.1:389
nisplusLDAPproxyUser
nisplusLDAPproxyPassword
To use transport layer security, set nisplusLDAPconfigTLS or nisplusLDAPTLS to ssl, and set nisplusLDAPconfigTLSCertificateDBPath or nisplusLDAPTLSCertificateDBPath to the file containing the certificate database. In order to successfully use authentication and transport layer security, the server must also support the chosen values.
To change the TTLs, edit the nisplusLDAPentryTtl for the appropriate database ID. To change LDAP container locations or object classes, edit the nisplusLDAPobjectDN value for the appropriate database ID.
The nisplusObjectContainer, nisplusObject, and ou=nisPlus labels are suggestions. If you change nisplusObjectContainer, or ou=nisPlus, edit the mapping file to reflect this. To change nisplusObject, for example, to myObject, add nisplusObject=myObject to the filterAttrValList and attrValList portions of the readObjectSpec and writeObjectSpec of the nisplusLDAPobjectDN value for the mapping. See the description of nisplusLDAPobjectDN below.