Home > Articles > Operating Systems, Server > Solaris

  • Print
  • + Share This
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.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 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 
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 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 
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.0NAME 
'nisplusAuthName' 
SUP top AUXILLIARY DESC 'NIS+ authentication
 identifiers' MAY ( nisplusPrincipalName $ nisplusNetname ) )

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   
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):

  1. Start the search as ou=Hosts,dc=example,dc=com

  2. Perform a one-level search (do not search below ou=Hosts).

  3. 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: 
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 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,
 (name)=(cn), addr=ipHostNumber, 
comment=description

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.

  1. Directory Server address and port number.

  2. In the rpc.nisd file, change: preferredServerList=127.0.0.1:389

  3. Authentication Method:

  4. nisplusLDAPproxyUser

  5. The bind-DN to use for authentication:

  6. nisplusLDAPproxyPassword

  7. Transport Security:

  8. 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.

  9. Time-to-Live Parameters

  10. 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.

  11. NIS+ Table Object Support

  12. 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.

  • + Share This
  • 🔖 Save To Your Account