Principal Names and Netnames

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

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

user or system.x.y.z.

Netnames are of the following form.

unix.uid@x.y.z.

unix.nodename@x.y.z.

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

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

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

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

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

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

    credname.sub.dom.ain.

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

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

    Edit the mapping file. Change

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

    to

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

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

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

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

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

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

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

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

  # pkill rpc.nisd

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

client_info and timezone Tables

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

client_info Attributes and Object Class

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

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

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

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

dn: ou=ClientInfo, searchBase

objectClass: organizationalUnit

ou: ClientInfo

objectClass: top

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

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

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

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