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]